Token Extensions là gì?

Chương trình token hiện tại trên Solana

Tất cả token trên Solana không phải token $SOL gốc đều được xem là token SPL. Điều này bao gồm cả token có thể thay thế (như $BONK) và token không thể thay thế (NFT). Chương trình token là một chương trình xác định các chức năng chung để tạo và làm việc với cả token có thể thay thế lẫn token không thể thay thế. Chương trình token cung cấp một số tính năng mà các nhà phát triển và người dùng cuối đã quen thuộc. Các thao tác này gồm đúc, chuyển và đốt token. Ngoài ra, chương trình còn có các chức năng như cập nhật và đóng băng token, cho phép đóng băng một tài khoản token để ngăn mọi thay đổi đối với trạng thái tài khoản cho đến khi tài khoản được mở đóng băng.

Token Extensions là gì và tại sao cần đến công nghệ này?

Có thể xem Token Extensions là phiên bản mới và cải tiến của chương trình token trên Solana. Chương trình này có thể xử lý cả token có thể thay thế và token không thể thay thế. Chương trình mới vẫn có đầy đủ tính năng của chương trình Token cũ, nhưng nay đi kèm một bộ tính năng mới hữu ích được thiết kế để cải thiện chức năng token trên Solana. Những tính năng mới này — điểm tạo nên sức mạnh thực sự của Token2022 — được cung cấp dưới dạng các phần mở rộng.

Nhưng tại sao cần Token Extensions? Khi Solana phát triển, nhu cầu về các chức năng token phức tạp và linh hoạt hơn cũng tăng lên. Dù Chương trình Token hiện tại trên Solana đã đáp ứng các nhu cầu cơ bản của token có thể thay thế và token không thể thay thế bằng một bộ tính năng đơn giản, chính sự đơn giản này lại tạo ra những hạn chế có thể cản trở đổi mới. Các nhà phát triển với những ý tưởng mới thường phải fork Chương trình Token để bổ sung chức năng cần thiết, gây khó khăn cho việc đạt được mức độ áp dụng rộng rãi. Mô hình lập trình của Solana yêu cầu đưa cả chương trình và tài khoản vào giao dịch, khiến việc tạo các giao dịch liên quan đến nhiều chương trình token trở nên phức tạp. Ngoài ra, ví và các chương trình on-chain phải tin cậy mọi chương trình token mà chúng chọn hỗ trợ, điều này có thể tiềm ẩn rủi ro. Để đáp ứng bối cảnh đang thay đổi này, Solana giới thiệu Token2022 — một bộ tính năng bổ sung và cải tiến được thiết kế để mở rộng khả năng của token trong hệ sinh thái.

Giới thiệu các phần mở rộng: Một bước tiến hóa

Khả năng mang tính đột phá của tiêu chuẩn mới này nằm ở các phần mở rộng hiện có, một bộ trường mới được giới thiệu để đáp ứng nhiều nhu cầu khác nhau. Nói đơn giản, trong bối cảnh Token Extensions, phần mở rộng là một tính năng hoặc chức năng bổ sung có thể được thêm vào token để nâng cao khả năng và tính hữu dụng của token đó. Các phần mở rộng cho phép người tạo token tùy chỉnh hành vi và đặc điểm của token để phù hợp với nhu cầu hoặc mục tiêu cụ thể. Khi tạo token, bạn có thể chọn sử dụng số lượng phần mở rộng bất kỳ. Hãy cùng phân tích một số phần mở rộng chính và tác động tiềm năng của chúng đối với hệ sinh thái Solana. Cần lưu ý rằng hiện chưa phải tất cả các phần mở rộng này đều đã hoạt động.

Phần mở rộng mint

Dưới đây là phần giải thích cho từng phần mở rộng mint:

1. Phí chuyển token

Trong khi chương trình Token hiện tại không cho phép thu phí khi chuyển token, tiêu chuẩn Token Extensions thay đổi điều này bằng cách cho phép cấu hình phí chuyển token ở cấp giao thức. Cơ chế này mang đến một cấp độ kiểm soát tài chính mới đối với giao dịch.

2. Hook chuyển token

Phần mở rộng Transfer Hook cung cấp cho người tạo token thêm một lớp kiểm soát đối với hoạt động chuyển token. Điều này đặc biệt quan trọng khi xử lý các thách thức liên quan đến tiền bản quyền NFT. Phần mở rộng Transfer Hook hoạt động bằng cách cho phép người tạo token xây dựng các chương trình tùy chỉnh mà token sẽ sử dụng mỗi khi được chuyển. Khi một giao dịch chuyển token được khởi tạo, token sẽ giao tiếp với chương trình tùy chỉnh này, qua đó cho phép thực hiện mọi hành động tiếp theo.

3. Đóng mint

Token Extensions khắc phục một thiếu sót đáng kể trong chương trình Token bằng cách cho phép một địa chỉ được chỉ định đóng tài khoản mint, điều trước đây không thể thực hiện. Việc này được tiến hành bằng cách khởi tạo phần mở rộng MintCloseAuthority trước khi khởi tạo mint. Nhờ đó, một người không phải ví có thẩm quyền cũng có thể đóng mint của token.

4. Token sinh lãi

Token Extensions giới thiệu phần mở rộng InterestBearingMint, cho phép biểu thị lượng token trên giao diện người dùng theo cách khác, có tính đến phần lãi đã tích lũy. Về cơ bản, tính năng này cho phép token “sinh lãi”, khiến chúng có giá trị hơn khi bạn nắm giữ lâu hơn.

5. Token không thể chuyển nhượng (token Soulbound)

Phần mở rộng mint NonTransferable cho phép tạo các token "soul-bound" không thể di chuyển khỏi ví. Đây là lựa chọn lý tưởng để ghi nhận thành tích hoặc trao phần thưởng độc nhất. Các token này cũng rất phù hợp để làm vé sự kiện vì bạn không thể gửi vé đó cho bất kỳ ai khác.

6. Chuyển token bảo mật

Token Extensions giới thiệu một Phần mở rộng Token Bảo mật mới có tên Confidential Transfers — một tính năng bảo vệ quyền riêng tư sử dụng bằng chứng không tiết lộ để mã hóa số dư token và số lượng chuyển của token SPL.

Mục tiêu tổng thể của phần mở rộng này là cải thiện quyền riêng tư của người dùng bằng cách tập trung vào tính bảo mật thay vì tính ẩn danh. Vì số dư có thể được cộng hoặc trừ, tiêu chuẩn Token Extensions yêu cầu một cơ chế mã hóa cho phép thực hiện các phép toán ẩn này; cơ chế mã hóa phải có tính đồng cấu. Mã hóa đồng cấu là một lớp cơ chế mã hóa đặc biệt, cho phép thực hiện một số loại phép tính nhất định trên dữ liệu đã mã hóa mà không cần thực sự giải mã dữ liệu. Do đó, các phép tính ẩn này sẽ tạo ra một kết quả đã mã hóa mà khi giải mã sẽ tương đương với kết quả của việc áp dụng các phép toán tương tự trên văn bản thuần. Confidential Transfers sử dụng “Mã hóa Twisted ElGamal” để cho phép thực hiện các phép toán ẩn trên bản mã.

Dành cho những ai muốn tìm hiểu sâu hơn, Mã hóa Twisted ElGamal là một biến thể đơn giản của cơ chế mã hóa ElGamal tiêu chuẩn, trong đó bản mã được chia thành một cam kết Pedersen của thông điệp được mã hóa và một bộ xử lý giải mã để cho phép thực hiện các phép toán ẩn trên bản mã.

Confidential Transfers được xác thực bằng Sigma Protocols, một lớp bằng chứng không tiết lộ cụ thể, trong đó một bên (người chứng minh) có thể chứng minh cho bên kia (người xác minh) rằng họ biết một bí mật mà không tiết lộ chính bí mật đó. Các Sigma Protocols này cần thiết cho một số lệnh được cung cấp cùng phần mở rộng. Hãy phân tích từng loại bằng chứng:

Bằng chứng hợp lệ (khóa công khai)

• Xác minh rằng khóa công khai Twisted ElGamal được định dạng chính xác
• Có thể hình dung như việc xác thực “thẻ định danh kỹ thuật số” của người khác trước khi bắt đầu cuộc trò chuyện bảo mật
• Bằng chứng này cần thiết cho lệnh ConfigureAccount

Bằng chứng hợp lệ (bản mã)

• Đảm bảo thông điệp được mã hóa có cấu trúc hợp lệ
• Có thể hình dung như khi nhận một hộp được niêm phong — bạn biết hộp chưa bị can thiệp vì niêm phong vẫn còn nguyên
• Bằng chứng này cần thiết cho các lệnh Withdraw, Transfer và TransferWithFee

Bằng chứng số dư bằng không

• Chứng minh bản mã Twisted ElGamal mã hóa số không
• Có thể hình dung như cách kiểm tra số dư tài khoản ngân hàng của bạn bằng không mà không cần mở ứng dụng ngân hàng để xem
• Bằng chứng này cần thiết cho lệnh EmptyAccount

Bằng chứng bằng nhau

• Xác nhận hai kiểu bằng nhau — giữa hai bản mã ElGamal hoặc giữa một bản mã ElGamal và một cam kết Pedersen
• Có thể hình dung như có hai nhà kho khóa kín chứa đầy dụng cụ và chứng minh rằng cả hai có cùng bộ dụng cụ mà không thực sự mở chúng
• Bằng chứng này cần thiết cho các lệnh Transfer, TransferWithFee, WithdrawWithheldTokensFromMint và WithdrawWithheldTokensFromAccounts

Bằng chứng Sigma về phí

• Chứng minh phí chuyển token đã cam kết là chính xác
• Có thể hình dung như việc xác nhận với FedEx rằng bạn đã thanh toán thuế cho kiện hàng mà không cho họ biết chính xác số tiền phí đã trả
• Bằng chứng này cần thiết cho lệnh TransferWithFee

Bằng chứng phạm vi

• Xác nhận một số được mã hóa nằm trong một phạm vi nhất định
• Có thể hình dung như việc đoán chiều cao của một người và chứng minh dự đoán nằm trong một phạm vi chính xác nhất định mà không tiết lộ chiều cao thực tế của người đó
• Solana sử dụng Bulletproofs cho các bằng chứng này. Bạn có thể tìm hiểu thêm trong bài nghiên cứu học thuật này và phần triển khai dalek

Tóm lại; các bằng chứng không tiết lộ này được dùng để xác thực rằng một bên biết một bí mật mà bên kia có thể kiểm chứng mà không cần nói bí mật đó ra. Những loại bằng chứng khác nhau này giúp đảm bảo số dư và hoạt động chuyển token vận hành đúng về mặt toán học, đồng thời hoàn toàn riêng tư nhờ mã hóa.

Trong hệ thống bảo mật này, chỉ chủ tài khoản có khóa giải mã mới có thể xem số dư. Tuy nhiên, có những trường hợp một bên thứ ba bên ngoài cần kiểm tra số dư, chẳng hạn cho mục đích kiểm toán hoặc tuân thủ. Phần mở rộng Token Bảo mật hỗ trợ việc này thông qua hệ thống Global Auditor. Trong hệ thống này, mỗi tài khoản có thể có khóa giải mã riêng để chủ sở hữu cấp có chọn lọc quyền đọc cho các tài khoản cụ thể. Mint, tức thực thể phát hành tài sản, có một cấu trúc dữ liệu đặc biệt có thể tùy chọn bao gồm một “khóa mã hóa của kiểm toán viên” toàn cục. Mã như sau:

Transfer {
  amount_sender: PKE::encrypt(pke_pubkey_sender, 10),
  amount_receiver: PKE::encrypt(pke_pubkey_receiver, 10),
  amount_auditor: PKE::encrypt(pke_pubkey_auditor, 10),
  range_proof: RangeProof,
  equality_proof: EqualityProof,
  ...
}

Tham số amount_auditor là số lượng chuyển được mã hóa bằng khóa mã hóa công khai của kiểm toán viên. Bất kỳ ai có khóa bí mật của kiểm toán viên đều có thể giải mã amount_auditor, từ đó kiểm toán số lượng giao dịch của một mint cụ thể.

Nếu quan tâm đến bảo mật, có thể bạn đã nhận thấy một lỗ hổng tiềm ẩn trong thiết kế này. Giả sử Alice tạo bằng chứng dựa trên số dư được mã hóa của mình. Nhưng đồng thời, Bob gửi token cho Alice và giao dịch của anh ấy được xử lý trước. Khi đó, giao dịch của Alice bị từ chối vì bằng chứng đã tạo không phản ánh trạng thái tài khoản mới cập nhật. Kiểu tấn công này, được gọi là front-running, có thể khiến tài khoản của Alice không sử dụng được nếu Bob liên tục làm tràn mạng bằng các giao dịch chuyển đến tài khoản của Alice. Số dư được mã hóa của một tài khoản được chia thành số dư pending và số dư available để ngăn kiểu tấn công này:

let ct_pending = PKE::encrypt(pke_pubkey, 10);
let ct_available = PKE::encryption(pke_pubkey, 50);

Account {
    mint: Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB,
    owner: 5vBrLAPeMjJr9UfssGbjUaBmWtrXTg2vZuMN6L4c8HE6,
    encryption_key: mpbpvs1LksLmdMhCEzyu5UEWEb3dsRPbB5,
    pending_balance: ct_pending,
    account_balance: ct_available,
    ...
}

Mọi khoản tiền gửi đi đều được trừ khỏi số dư khả dụng, còn mọi khoản tiền nhận vào được cộng vào số dư đang chờ xử lý.

Confidential Transfers chưa hoạt động và tài liệu Solana cho các mục Giới thiệu và Hướng dẫn bắt đầu nhanh vẫn đang được phát triển. Tuy nhiên, bạn có thể theo dõi các tác vụ còn lại của Confidential Transfers qua issue GitHub này trên kho lưu trữ solana-program-library. Tài liệu có phần Phân tích chuyên sâu về giao thức, nhưng cần lưu ý rằng bạn không nhất thiết phải hiểu những nội dung được thảo luận trong phần phân tích chuyên sâu để sử dụng phần mở rộng. Bản tóm tắt dễ hiểu về Confidential Transfers trong các đoạn trên là quá đủ để bạn bắt đầu sử dụng Confidential Transfers sau khi mọi thứ đi vào hoạt động.

Phần mở rộng tài khoản

Dưới đây là phần giải thích cho từng phần mở rộng tài khoản:

1. Yêu cầu memo cho giao dịch chuyển đến

Token Extensions có một tính năng bắt buộc mọi giao dịch chuyển đến phải kèm memo. Memo về cơ bản là một thông điệp ngắn on-chain. Tính năng này giống như nhận được một tấm thiệp kèm theo quà tặng, nhờ đó bạn biết món quà đến từ ai và lý do họ tặng nó.

2. Quyền sở hữu bất biến

Phần mở rộng ImmutableOwner bổ sung một lớp bảo mật bằng cách ngăn việc chuyển nhượng lại quyền sở hữu tài khoản. Quy định này tăng cường độ an toàn cho các giao dịch token. Để hiểu rõ hơn, chúng ta cần xem cách token được lưu trữ trong chương trình token tiêu chuẩn. Thông thường, khi muốn gửi token đến một ví, bước đầu tiên là tạo một tài khoản token để lưu token đó trong ví của người nhận. Tài khoản này được tạo từ sự kết hợp giữa địa chỉ mint token và địa chỉ ví của người nhận. Mọi thứ đều ổn, ngoại trừ việc sau khi tài khoản được tạo, quyền sở hữu của tài khoản có thể được chuyển cho người khác. Với phần mở rộng Immutable Owner trong Token2022, điều này sẽ không còn xảy ra.

3. Trạng thái tài khoản mặc định

Phần mở rộng DefaultAccountState cho phép người tạo mint hạn chế việc sử dụng token bằng cách đặt tất cả tài khoản token mới ở trạng thái đóng băng theo mặc định. Tính năng này cung cấp thêm một lớp kiểm soát đối với việc phân phối và sử dụng token. Điều đó có nghĩa là bạn có thể nhận token nhưng không thể làm gì với token đó cho đến khi người tạo token cho phép.

4. Người được ủy quyền vĩnh viễn

Với Token Extensions, có thể chỉ định một người được ủy quyền tài khoản vĩnh viễn cho token. Về cơ bản, bạn có thể chỉ định một người luôn có thẩm quyền quản lý token từ một mint. Họ có thể thực hiện các thao tác như chuyển hoặc đốt token. Nếu sử dụng phần mở rộng này, người có thẩm quyền sẽ có đặc quyền ủy quyền không giới hạn đối với mọi tài khoản thuộc mint đó. Điều này có thể rất nguy hiểm vì người được ủy quyền có thể chuyển hoặc đốt token trong ví của bất kỳ ai.

Token Extensions so với Ethereum và Binance Smart Chain (BSC)

Ethereum và Binance Smart Chain (BSC) đã đạt được những bước tiến đáng kể trong lĩnh vực DeFi, và chúng ta đã thấy một số tính năng của Token Extensions xuất hiện trên token của các chuỗi này.

Một ví dụ là SafeMoon trên BSC, áp dụng mức phí 10% cho mỗi giao dịch, trong đó 5% được phân phối lại cho những người nắm giữ SafeMoon khác. Điều này khuyến khích người dùng HODL. Khái niệm chuyển token bảo mật bằng bằng chứng không tiết lộ cũng không mới. Trên Ethereum, các dự án như Aztec Protocol đã thử nghiệm giao dịch riêng tư.

Dù Solana triển khai các tính năng này chậm hơn đôi chút, tốc độ vượt trội và chi phí giao dịch thấp hơn tạo ra môi trường thuận lợi để Token Extensions phát triển, từ đó mang lại lợi thế cạnh tranh trước Ethereum và BSC.

Những dự án sớm áp dụng Token Extensions

Các nhà phát triển, dApp và ví cần thích nghi với những chức năng mới này để tận dụng tối đa những gì Token Extensions cung cấp. Dưới đây là một số trường hợp sớm áp dụng chương trình mới:

$BERN / BonkEarn

$BERN, do cộng đồng $BONK tạo ra, là một trong những token đầu tiên được xây dựng trên chương trình Token Extensions. Hiện tại, $BERN sử dụng phần mở rộng Transfer Fee để thu phí 6,9% trên mọi giao dịch chuyển. Đội ngũ $BERN sử dụng khoản phí này để thưởng cho cả người nắm giữ $BERN lẫn người nắm giữ $BONK.

Phân tích đầy đủ:

• 5% dành cho “Bernzy Bonus Fee” để thưởng cho người nắm giữ $BERN
• 1% dùng để mua và đốt $BONK
• 0,5% dùng để đốt $BERN
• 0,3% được chuyển vào quỹ nhà phát triển để thanh toán thêm phí và bổ sung vào pool thanh khoản của token.
• 0,1% được chuyển đến DAO $BONK

Sàn giao dịch phi tập trung

FluxBeam là một DEX trên Solana hiện hỗ trợ các token được tạo bằng chương trình Token Extensions.

Ví

Backpack, một tiện ích ví phổ biến, đã hỗ trợ Token Extensions và Phantom sẽ sớm có chức năng này.

Công cụ

Các công cụ để tự đúc token bằng chương trình Token Extensions hiện đã hoạt động trên FluxBeam.

RugCheck là một công cụ để tìm hiểu thị trường token Solana và các token khác nhau. Công cụ này đã hỗ trợ kiểm tra các token được xây dựng bằng Token 2022.

Đón nhận tương lai

Sự ra mắt của Token Extensions là một bước tiến lớn trong hành trình web3 của Solana. Công nghệ này mang đến hàng loạt chức năng mới, đồng thời tăng cường khả năng của các tính năng hiện có. Những phần mở rộng đột phá không chỉ trao cho người tạo token nhiều quyền kiểm soát và sự linh hoạt hơn mà còn mở ra các khả năng mới trong lĩnh vực DeFi. Dù các blockchain khác đã cung cấp những tính năng tương tự, lợi thế về tốc độ và chi phí của Solana, kết hợp với các chức năng của Token2022, tạo nên một đối thủ đáng gờm trong thế giới tiền mã hóa. Khi sự hỗ trợ từ những người dùng tiên phong và cộng đồng rộng lớn tiếp tục tăng lên, Token2022 đã sẵn sàng nâng cao và phát triển hệ sinh thái Solana.