Mọi người đều đang nói về Sự trừu tượng tài khoản (AA) và tiềm năng của nó để cách mạng hóa trải nghiệm người dùng trong không gian blockchain. Tuy nhiên, sự hiểu lầm chính về AA là nó vượt xa việc trừu tượng hóa phí gas hoặc kích hoạt giao dịch hàng loạt. Làm thế nào? Thông qua hệ thống quản lý khóa có thể lập trình được.

Các hệ thống này có thể cung cấp bảo mật cấp phần cứng cho các thiết bị hàng ngày và tích hợp các phương pháp xác thực Web2 vào môi trường Web3, cho phép chúng ta vượt xa các cụm từ gốc 12 từ truyền thống. Hôm nay, tôi sẽ giải thích về các hệ thống quản lý khóa khác nhau mà các nhà phát triển có thể sử dụng và các trường hợp sử dụng cụ thể mà chúng hữu ích nhất.

Vượt qua 12 từ

Ngành công nghiệp của chúng ta yêu thích các thuật ngữ ấn tượng, và “seedless” là một trong những thuật ngữ mới nhất thu hút sự chú ý. Trong khi chúng ta đều đồng ý rằng mong đợi người dùng lưu trữ các khóa riêng tư của họ một cách an toàn là không thực tế và đã dẫn đến việc mất hàng triệu đô la, câu hỏi đặt ra là: nếu chúng ta không hiển thị các cụm từ hạt giống cho người dùng, chúng ta sẽ lưu trữ các khóa ở đâu?

Mà không cần tài khoản Abstraction (AA), hầu hết các giải pháp hiện có dựa vào Multi-Party Computation (MPC) để phân phối khóa thành nhiều phần và tạo ngưỡng cho việc thực hiện giao dịch. Các giải pháp này thường tuyên bố là tự quản lý. Tuy nhiên, điều này không hoàn toàn chính xác. Ví dụ, Binance lưu trữ một phần của khóa, đóng vai trò là người giám hộ trong trường hợp người dùng mất thiết bị của họ. Thiết lập này có nghĩa là, mặc dù có tuyên bố, người dùng không hoàn toàn kiểm soát khóa của họ, và vẫn phụ thuộc vào một thực thể tập trung để phục hồi khóa.

Hơn nữa, nếu bất kỳ khóa nào bị rò rỉ, không có cách nào để thu hồi khóa từ tài khoản chính. Việc thu hồi là không thể thi hành vì Tài khoản Sở hữu Bên ngoài (EOAs) không hỗ trợ việc xoay vòng khóa, có nghĩa là khóa bị rò rỉ sẽ luôn là một phần của tài khoản. Điều này tạo ra một rủi ro bảo mật đáng kể, vì các khóa bị nhiễm bị không thể được thay thế hoặc loại bỏ, để lại tài khoản dễ bị tấn công mãi mãi.

Nếu bạn muốn tìm hiểu thêm về cách AA mở ra cách thức cho các tài khoản có thể lập trình và xoay chìa khóa, bạn có thểkiểm tra bài viết của tôi.

1. Tài khoản có thể lập trình hoàn toàn: Sự trừu tượng tài khoản

Trừu tượng hóa tài khoản cho phép các nhà phát triển xây dựng các hệ thống quản lý khóa khác nhau. Một tài khoản có thể được kiểm soát bằng nhiều khóa và các phương thức xác thực khác nhau, tất cả đều hỗ trợ xoay khóa. Thậm chí tốt hơn, sức mạnh của các phím có thể được phân biệt. Điều này có nghĩa là người dùng có thể sử dụng các khóa khác nhau cho cùng một tài khoản, mỗi khóa được điều chỉnh cho các trường hợp sử dụng khác nhau. Tôi sẽ giải thích các trường hợp sử dụng này chi tiết hơn sau.

Với AA, các quỹ được lưu trữ trong hợp đồng thông minh, và quyền sở hữu tài khoản được xác định bởi những hợp đồng thông minh này. Các tài khoản tương thích với EIP-4337 có hai phần trong giao dịch của họ.

1. Phần đầu tiên là xác minh, nơi sở hữu tài khoản được xác minh trên chuỗi.
2. Phần thứ hai là thi hành, thực hiện tin nhắn.

Hai phần này hoàn toàn có thể lập trình; ví dụ, bạn có thể xác định hai phím (i, ii), và phím đầu tiên (i) có thể thực hiện giao dịch ngay lập tức, trong khi phím thứ hai (ii) chỉ có thể thực hiện giao dịch sau khi khóa thời gian. Điều này có nghĩa là chúng ta có thể xác định quyền lực của các phím, thêm khóa thời gian, hoặc kích hoạt các điều kiện khác để thực hiện một giao dịch.

Vì vậy, khi chúng ta nói về tài khoản truyền thống (EOAs), xác thực bằng quyền hạn. Với AA, quyền hạn có thể được lập trình, vì vậy các nhà phát triển có thể xác định một lược đồ kiểm soát truy cập dựa trên vai trò và áp dụng nguyên tắc ít đặc quyền.

Có nhiều phương pháp xác thực (tức là các hệ thống quản lý khóa) trong không gian tiền điện tử có thể kích hoạt các hệ thống kiểm soát truy cập dựa trên vai trò, và việc sử dụng chỉ một khóa không thể giải quyết tất cả các vấn đề liên quan đến quản lý khóa. Những khía cạnh quan trọng nhất của các hệ thống quản lý khóa là: nơi khóa được lưu trữ và ai xác thực nó.

Ưu điểm và nhược điểm của các hệ thống quản lý khóa khác nhau

Tôi sẽ tóm tắt nhanh về Passkeys (Consumer Secure Enclaves), các giải pháp dựa trên MPC, các giải pháp dựa trên đám mây TEE, các giải pháp giữ tài sản, Các từ khóa truyền thống 12 từ và Session Keys. Sau đó, tôi sẽ giải thích các tổ hợp tốt nhất.

1. Từ 12 truyền thống - (secp256k1) -

Bitcoin và Ethereum hỗ trợsecp256k1Thuật toán ECC (elliptic curve cryptography) để tạo khóa riêng và lưu trữ chúng trên thiết bị của người dùng. Phương pháp này được sử dụng rộng rãi trong EOAs và cũng có thể áp dụng chotài khoản thông minhĐể sử dụng nó, ứng dụng ví tạo ra một khóa riêng tư bằng cách sử dụng thuật toán tạo khóa ngẫu nhiên và sau đó lưu trữ khóa riêng tư trong bộ nhớ lưu trữ chung.

Sử dụng secp256k1 có một số lợi ích: không tốn phí gas phụ, rẻ tiền và dễ dàng xác minh trên chuỗi thông qua ecrecover precompile. Nó cũng tự giữ vì chỉ người dùng mới có thể truy cập vào khóa.

Tuy nhiên, cũng có một số nhược điểm:

1. Việc giáo dục người dùng về cách lưu trữ an toàn khóa của họ trong trường hợp họ mất thiết bị là thách thức.
2. Một trojan hoặc phần mềm độc hại có thể đánh cắp khóa riêng từ thiết bị của người dùng vì nó được lưu trữ trong bộ nhớ chia sẻ.

NIST không hỗ trợ đường cong secp256k1, điều này có nghĩa là nó không được hỗ trợ phổ biến bởi các khung vi mạch phổ biến và hầu hết phần cứng.

2. Passkeys (Khu vực An toàn Người tiêu dùng)

Hầu hết các thiết bị hiện đại đều có hai thành phần chính: hệ điều hành (với lưu trữ chia sẻ liên quan) và một Secure Enclave. Hệ điều hành xử lý hầu hết các hoạt động ngoại trừ các tác vụ nhạy cảm như bảo vệ dữ liệu sinh trắc học, các khóa mật mã, mã hóa và mở khóa thiết bị.

Các nhà phát triển đã tạo ra một vi mạch riêng gọi là Secure Enclave để quản lý những hoạt động nhạy cảm này một cách riêng biệt. Secure Enclave hoạt động tương tự như một ví cứng; nó hoạt động độc lập, xử lý dữ liệu nhạy cảm một cách an toàn và ngay cả chủ sở hữu thiết bị cũng không thể truy cập vào nội dung của nó. May mắn thay, Secure Enclave hỗ trợ các hoạt động mật mã học, chẳng hạn như tạo khóa riêng và ký các thông điệp bằng chúng. Rất tiếc là Secure Enclave không hỗ trợ đường cong mà Ethereum hỗ trợ (secp256k1), thay vào đó nó hỗ trợ đường cong p256. Để kích hoạt xác minh P256 gốc, chúng tôi (@getclave“”>Đội @getclave đề xuấtRIP-7212và gần như tất cả các rollups lớn hiện nay đều hỗ trợ nó.

Và phần tốt nhất về Secure Enclaves là chúng ta có thể tạo ra một khóa riêng tư bên trong Secure Enclaves chỉ với xác thực sinh trắc học mà cho phép trải nghiệm onboarding chỉ với một cú nhấp chuột với bảo mật tốt nhất có sẵn trên các thiết bị hiện đại - cấp phần cứng. Nhưng nó cũng có một số hạn chế:

• Xác minh P256 mà không có RIP-7212 là đắt đỏ và tăng nguy cơ lỗi.
• Vì khóa không thể được trích xuất, tính khả khôi phục đã bị thiếu ở đây (Passkeys cho phép khả năng khôi phục hạn chế nhưng không đủ)
• Nếu tên miền web của passkey, hoặc ứng dụng Secure Enclave (SE) bị ngừng hoạt động, người dùng không thể truy cập vào khóa riêng tư vì Secure Enclave được thiết kế để cô lập và độc lập. Mà không có ứng dụng hoặc tên miền web liên quan, không có cách nào để khôi phục hoặc tương tác với khóa riêng tư, khiến người dùng không thể thực hiện các hoạt động mật mã cần thiết. - Tôi sẽ giải thích cách giải quyết vấn đề này.

3. Giải pháp quản lý khóa dựa trên SSS

Các giải pháp SSS (Chia sẻ bí mật Shamir) tạo ra một cách để loại bỏ điểm thất bại đơn lẻ mà hệ thống quản lý khóa truyền thống có. Theo cách cơ bản, chúng phân chia các khóa thành các phần khác nhau và thiết lập một ngưỡng để truy cập vào khóa. Bằng cách phân phối các phần này, SSS đảm bảo rằng không có một thực thể duy nhất nắm giữ toàn bộ khóa, từ đó nâng cao tính bảo mật.

Hãy xem xét nơi họ lưu trữ các khóa và cách họ đạt đến thỏa thuận để truy cập vào khóa riêng. Hầu hết các giao thức hiện có sử dụng ba phần khóa: một phần được lưu trữ trên thiết bị người dùng, một phần được giữ trên máy chủ của họ (hoặc trong Mạng MPC), và một phần được dành làm bản sao lưu. Một số ứng dụng, như Google Drive, sử dụng các giải pháp lưu trữ đám mây để lưu trữ các phần khóa này.

Vì vậy, người dùng ủy quyền quyền kiểm soát ví của họ cho các bên thứ ba với một quorum. MPC (Multi-Party Computation) mạnh mẽ trong việc ủy quyền trách nhiệm quản lý khóa cho các bên khác nhau, nhưng nó cũng có một số điểm hạn chế:

Hầu hết các giải pháp MPC đòi hỏi một bên trung tâm, và đôi khi, những gì họ gọi là phi tập trung thực sự không phải là phi tập trung. MPC với AA mạnh mẽ vì quay khóa là có thể, nhưng nhiều giải pháp MPC bao gồm một số chức năng để gatekeeping. Đôi khi trong nhiều trường hợp, khóa trước đó vẫn có thể được sử dụng ngay cả sau khi quay, vì vậy người ta cần phải tin rằng các khóa thực sự được vứt bỏ. Một số giải pháp MPC có thể kiểm duyệt người dùng, vì vậy chỉ tin cậy vào MPC không luôn khả thi.

Một hạn chế chính khác của SSS là nó phục hồi lại khóa riêng tư, thường là trong trình duyệt. Điều này là một rủi ro bảo mật lớn khi khóa văn bản thuộc sở hữu của người dùng có thể sẵn có trên máy khách. TSS không bao giờ phục hồi lại khóa và sử dụng MPC để liên kết việc ký trên các phần chia khóa.

4. Giải pháp TEE dựa trên đám mây

Tôi không nghĩ rằng Môi trường Thực thi Đáng tin cậy Dựa trên Đám mây (TEEs) và các giải pháp dựa trên SSS khác nhau, nhưng tôi vẫn muốn giải thích cách chúng hoạt động. Môi trường Thực thi Đáng tin cậy hoạt động chính xác như cách chúng được lập trình; chúng không thể thay đổi (ít nhất là chúng tuyên bố là không thể thay đổi), và TEE không hiển thị những gì có bên trong ngay cả với chủ sở hữu TEE. Chúng được thiết kế để hoạt động với tính toàn vẹn - làm đúng điều đúng ngay cả khi không có ai xem. Vì vậy, khóa không bao giờ được tiết lộ cho khách hàng ngay khi TEE đang hoạt động đúng.

Bằng cách sử dụng TEE, chúng ta có thể xây dựng các lớp quản lý khóa mà trong đó các nhà phát triển có thể sử dụng các phương thức xác thực khác nhau, và TEE có thể xác minh chúng. Sau khi xác minh, TEE ký một tin nhắn bằng khóa riêng tư liên quan đến người dùng và xác minh nó trên blockchain.

Khóa riêng tư chính quyền chứa quản lý quỹ người dùng được lưu trữ bên trong TEE và không thể được trích xuất. Điều này đe dọa sự phi tập trung vì nếu dịch vụ quyết định đóng cửa hoặc kiểm duyệt người dùng, không có gì mà người xây dựng ứng dụng có thể làm.

TEE dựa trên đám mây có vẻ hứa hẹn trong lý thuyết, nhưng trong quá khứ, chúng ta đã thấy những lỗ hổng như sgx.failtrong TEE đám mây. Tuy nhiên, lợi thế của TEE là ngay cả khi có lỗ hổng hoặc lỗ hổng, kẻ tấn công cũng cần truy cập vật lý vào TEE, đó là lý do tại sao phần cứng người dùng (Secure Enclave - Passkeys) rất mạnh mẽ vì phần cứng người dùng lưu trữ khóa bên trong Secure Enclave của người dùng và chỉ chủ sở hữu mới có thể truy cập khóa, trong khi Cloud TEE lưu trữ khóa trong một đám mây và điều này khiến nó trở nên dễ bị tấn công.

Không phải là pháo đài bảo mật của bạn, không phải là đồng xu của bạn.

Như tôi đã đề cập, TEEs có một số ưu điểm, như sử dụng gần như tất cả các phương pháp xác thực mà không có bất kỳ rào cản mật mã nào. Tuy nhiên, chúng cũng có một số nhược điểm:

Nếu nhà cung cấp dịch vụ tắt máy chủ, nguồn tiền của người dùng sẽ bị đóng băng và không ai có thể truy cập chúng. Các khóa được lưu trữ bên trong Cloud TEE, điều này có nghĩa là họ có thể kiểm duyệt người dùng. Chỉ tin cậy vào TEEs cho việc quản lý khóa tạo ra một điểm hỏng.

Session Keys: Một cách mới để giới hạn quyền hạn

Chúng ta đã nói về các khóa vĩnh viễn. Nhưng nếu chúng ta có thể tạo ra một khóa tạm thời chỉ có quyền truy cập giới hạn vào tài sản và biến mất sau một khoảng thời gian do người dùng quyết định? Khóa phiên cho phép chúng ta làm điều đó:

Trong thế giới web2, các khóa phiên giống như là mật khẩu tạm thời được sử dụng trong quá trình trò chuyện giữa hai thiết bị (như máy tính của bạn và một máy chủ). Chúng được tạo ra ở đầu cuộc trò chuyện, được sử dụng để giữ thông tin được chia sẻ an toàn, và sau đó bị loại bỏ sau khi cuộc trò chuyện kết thúc. Do đó, ngay cả khi một hacker nào đó tìm ra được mật khẩu này, họ cũng không thể sử dụng nó để nghe trộm trong các cuộc trò chuyện trong tương lai vì mỗi lần đều tạo ra một mật khẩu khác nhau (hoặc khóa phiên).

Tựa như trong thế giới Web3, chúng tôi xác định session keys là một khung việc có thể thay đổi cách người dùng tương tác với dApps. Mục tiêu của session keys là cho phép người dùng thiết lập sự chấp thuận trước cho một khoảng thời gian cụ thể trong nhiều kịch bản khác nhau và thực hiện giao dịch mà không cần ký. Nhưng nó hoạt động như thế nào?

Người dùng tạo một quyền hạn giới hạn giống như một khóa phiên mà chỉ có thể chi tiêu tài sản theo yêu cầu của người dùng, trong một khoảng thời gian giới hạn, và có thể thu hồi bất kỳ lúc nào. Sau đó, một dịch vụ backend cho phép người dùng tiến hành giao dịch bằng cách ký thay mặt họ. Thiết lập này tạo ra một cửa sổ tin cậy tạm thời giữa dApp và người dùng. Điều này tốt hơn nhiều so với việc cho phép vô hạn vì sự cho phép mà người dùng cung cấp chỉ dành cho tài sản cụ thể và trong một khoảng thời gian xác định. Ngay cả khi dApp bị hack, người dùng cũng không cần lo lắng về một khóa phiên đã tạo từ vài tháng trước 🙂.

Các kết hợp xác thực và quản lý khóa tốt nhất cho các trường hợp sử dụng khác nhau

Tôi đã giải thích các hệ thống quản lý khóa khác nhau và ưu, nhược điểm của chúng. Với sức mạnh của AA, chúng ta có thể kết hợp những hệ thống quản lý khóa này và tạo ra các cấu trúc mạnh mẽ với sự đánh đổi tối thiểu. Hãy giải thích nó C.1) Passkey + khôi phục với khóa thời gian - Clave - một ứng dụng fintech lưu trữ các quỹ có giá trị.

Phương pháp xác thực dựa trên Secure Enclave (passkeys) cung cấp bảo mật cấp phần cứng; tuy nhiên, khả năng khôi phục của chúng thường không đủ cho hầu hết người dùng. May mắn thay, AA cho phép các nhà phát triển kết hợp các phương pháp ký khác nhau và sử dụng chúng trong một tài khoản. Bằng cách thêm người ký khôi phục vào một tài khoản thông minh, chúng ta có thể giải quyết vấn đề khôi phục mà passkeys đang gặp phải.

Có một số lựa chọn phục hồi như phục hồi xã hội, phục hồi toàn cầu (phục hồi dựa trên ZK-Email), và phục hồi dựa trên MPC. Tuy nhiên, theo ý kiến của tôi, đối với một ứng dụng fintech được thiết kế để hoàn toàn tự lưu trữ, phục hồi xã hội giải quyết hầu hết các vấn đề. Tại Clave, chúng tôi đã xây dựng một mô-đun phục hồi xã hội và đang làm việc trên Phục hồi Toàn cầu.

Phương pháp này tối đa hóa bảo mật, điều đó rất tốt cho các ứng dụng tài chính. Nhưng nó có một hạn chế quan trọng: ứng dụng yêu cầu xác thực sinh trắc học cho mỗi giao dịch mà người dùng muốn thực hiện. Hãy tưởng tượng rằng bạn muốn chia sẻ một nội dung trên ứng dụng mạng xã hội và ứng dụng hiển thị một màn hình đăng ký sinh trắc học… Tệ quá phải không?

Các ứng dụng không tài chính như các ứng dụng xã hội-Fi và trò chơi phi tập trung cần một cách dễ dàng hơn để tiến hành giao dịch, lý tưởng là không yêu cầu người dùng ký mỗi giao dịch. Làm thế nào? Đây là câu trả lời:

1. Passkey + recovery with timelock + session keys — ứng dụng xã hội di động

Session keys cho phép người dùng thực hiện giao dịch mà không cần màn hình ký. Các trò chơi hoặc ứng dụng xã hội dựa trên NFT có thể kế thừa session keys để có quyền truy cập tạm thời và giới hạn đến tài sản của người dùng. Nếu bạn nghĩ rằng điều này tạo thêm giả định về sự tin tưởng, hãy để chúng tôi giải thích cách giao diện người dùng hiện tại hoạt động:

Hôm nay, hầu hết người dùng thậm chí không kiểm tra họ đang ký vào khi chơi game hoặc tương tác với một ứng dụng phi tập trung. Điều này nguy hiểm vì một giao diện trước độc hại có thể khiến người dùng mất tất cả tài sản của họ.

Khóa phiên là một sự thay thế tốt hơn cho việc này. Người dùng có thể kiểm tra thời gian hoạt động của phiên và tài sản nào mà phiên có thể truy cập, giảm thiểu nhu cầu tin cậy vào ứng dụng phiên. Sau khi thời gian phiên hết hạn, người dùng không cần lo lắng về việc phê duyệt = Không cần nữarevoke.cashthích các ứng dụng :)

2. MPC hoặc chữ ký dựa trên cloud TEE + chữ ký tự lưu trữ cho việc thoát

Hạn chế của các lớp quản lý khóa của bên thứ ba dựa trên MPC hoặc Cloud TEE là hầu hết không tự giám sát và có các thành phần tập trung đáng kể. Tuy nhiên, một số dApp yêu cầu ví nhúng mà không cần thêm chi phí gas, đòi hỏi các giải pháp dựa trên MPC hoặc Cloud TEE. Thêm một người ký thêm cho “cơn thịnh nộ bỏ cuộc” có thể giải quyết vấn đề kiểm duyệt mà các hệ thống quản lý chính này gặp phải và cũng giảm thiểu các vấn đề pháp lý tiềm ẩn mà các dApp này có thể gặp phải. Bạn cần một ví thông minh để xây dựng điều này vì không thể xoay vòng khóa với EOA.

Hiện đã có một số ứng dụng sử dụng kiến trúc quản lý khóa này.

3. 12 từ + Bộ ký hiệu phần cứng để tối đa hóa bảo mật - Trải nghiệm tiện ích trình duyệt DeFi

Người dùng DeFi thích trải nghiệm tiện ích trình duyệt và thay đổi hành vi người dùng là một trong những điều khó nhất trong thế giới hiện đại. Vậy tại sao không xây dựng một giải pháp thay thế tốt hơn? Kết hợp một bộ ký hiệu phần cứng (Secure Enclave hoặc Passkey Signer) với cụm từ gốc 12 từ có thể truy cập thông qua một tiện ích mở rộng cũng có thể giải quyết vấn đề rò rỉ khóa riêng tư. Phương pháp này cải thiện bảo mật mà không cần thay đổi hành vi của người dùng. Một số nhóm trong ngành AA đang làm việc để kích hoạt điều này. (Ví dụ, @myBraavos)

Tài khoản thông minh không đủ thông minh

Hãy tưởng tượng bạn là một người dùng lần đầu tiên tạo ra một EOA với @MetaMaskvà sau đó phát hiện ra một lựa chọn như Zerion. Bạn quyết định sử dụng @zerion, và tất cả những gì bạn cần làm là nhập cụm từ khóa của bạn - đơn giản thôi. Bây giờ, hãy tưởng tượng cố gắng làm điều tương tự trên Starknet, nơi tất cả ví đều là tài khoản thông minh. Bạn không thể, bởi vì Braavos và Argent không tương thích. Vấn đề này cũng tồn tại trong hệ sinh thái EIP-4337 và @zkSyncAA bản địa của gate.

Chúng ta cần các tiêu chuẩn (không phải là người kiểm soát cổng) hoặc ít nhất là một cách tốt hơn để tài trợ cho các ví mới. Nếu không, sẽ không bao giờ có sự hiện diện rộng rãi của các ví thông minh, và những người chơi hiện tại sẽ vẫn là người ra quyết định, định đạo các thực hành ngành công nghiệp ngay cả khi chúng không đúng.

Ngoài ra, “rage quit” nên là một tính năng mặc định, vì những nhân vật trung tâm trong hầu hết các hệ thống quản lý chính có thể bị tắt. Người dùng nên dễ dàng thay đổi người ký hoặc chuyển đổi hợp đồng thông minh, và tự lưu trữ nên là tùy chọn mặc định cho người dùng. Hiện có hai tiêu chuẩn tài khoản thông minh modul: ERC-6900 và ERC-7579. Cả hai đều cố gắng đạt được một mục tiêu tương tự - làm cho tài khoản thông minh thông minh hơn.

Cảm ơn đặc biệt Derek ,Konrad, vàNoamcho phản hồi và nhận xét!

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được sao chép từ [BEYONDX]. Tất cả bản quyền thuộc về tác giả gốc [2077Nghiên cứu]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Cổng Họcteam, và họ sẽ xử lý nhanh chóng.
2. Từ chối trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không cấu thành lời khuyên đầu tư.
3. Nhóm Gate Learn đã dịch bài viết sang các ngôn ngữ khác. Việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là không được phép trừ khi được đề cập.