Token SPL và tài khoản token trong SSP
Nếu bạn từng dùng token ERC-20 trên Ethereum, mô hình token của Solana sẽ thấy quen chừng ba mươi giây rồi thôi không còn hợp lý nữa. Trên Ethereum, hợp đồng token giữ một sổ cái ghi ai sở hữu bao nhiêu, và địa chỉ của bạn xuất hiện như một dòng trong sổ ấy. Trên Solana, địa chỉ của bạn hoàn toàn không xuất hiện trong hồ sơ của token. Thay vào đó, một tài khoản riêng được tạo ra để giữ số dư của bạn đối với đúng token đó — thuộc về bạn nhưng tách biệt với địa chỉ chính.
Chỉ một quyết định thiết kế ấy giải thích gần như mọi bất ngờ người ta gặp với token SPL: vì sao gửi token cho một người mới tốn hơn gửi cho người đã giữ nó, vì sao ví có thể hiện số dư bằng không của một token với địa chỉ chưa từng chạm tới nó, và vì sao số thập phân ở đây quan trọng hơn bất cứ đâu. Bài viết này đi qua mô hình đó theo cách SSP triển khai.
Vì sao Solana cần một tài khoản riêng cho mỗi token
Quy tắc cốt lõi của Solana là mọi thứ đều là tài khoản, và mỗi tài khoản có chủ sở hữu, kích thước, cùng khoản ký quỹ tiền thuê tỉ lệ với kích thước ấy. Không có chuyện một hợp đồng lặng lẽ phình to một bảng ánh xạ nội bộ khi có thêm người dùng — chỗ lưu trữ phải nằm trong một tài khoản nào đó, và ai đó phải trả tiền cho nó.
Vì vậy chương trình SPL Token chia việc ra. Tài khoản mint giữ các dữ kiện về chính token: tổng cung, số thập phân, và ai được phát hành thêm. Mỗi người nắm giữ có tài khoản token riêng: một tài khoản nhỏ, kích thước cố định, ghi một số dư cho một mint và nêu tên một chủ sở hữu. Số dư SOL của bạn sống ở địa chỉ của bạn; số dư USDC của bạn sống trong một tài khoản token do địa chỉ của bạn kiểm soát.
Ưu điểm của thiết kế này là tính dự đoán được — mọi số dư token đều cùng một hình dạng và tốn như nhau để lưu. Cái giá là muốn giữ một token mới thì phải khai sinh một tài khoản mới. Tài liệu về token của Solana là nguồn sơ cấp nếu bạn muốn bản đặc tả thay vì bản tóm lược.
Tài khoản token liên kết, và ai trả tiền cho nó
Nếu mỗi người nắm giữ đều cần một tài khoản token, mà ai cũng có thể tạo tài khoản, bạn sẽ có nhiều tài khoản token cho mỗi người mỗi mint và chẳng có cách nào biết nên gửi vào cái nào. Tài khoản token liên kết — ATA — là quy ước giải quyết chuyện đó: với một chủ sở hữu và một mint cho trước, chỉ có một địa chỉ chuẩn tắc, được dẫn xuất tất định từ cả hai. Ví có thể tự tính ra, nên không ai phải công bố nó.
Vướng mắc nằm ở tiền thuê. Một tài khoản token nặng khoảng 165 byte, tương đương chừng 0,002 SOL bị giữ làm ký quỹ tiền thuê chừng nào tài khoản còn tồn tại. Khoản ký quỹ ấy lấy lại được khi đóng tài khoản, nhưng phải trả trước, và phải do người có SOL trả — điều mà người nhận lần chuyển token đầu tiên trong đời, theo định nghĩa, có thể không có.
SSP xử lý việc này giống như mọi khoản phí Solana khác. Khi bạn gửi token SPL cho người chưa có ATA, giao dịch bao gồm một lệnh idempotent để tạo nó, và paymaster của SSP trả tiền thuê. Kho của bạn hoàn lại cho paymaster ngay trong cùng giao dịch, và đó là lý do lần chuyển đầu tiên tới một người nhận mới tốn thêm khoảng 0,0025 SOL so với lần chuyển lặp lại tới cùng người ấy. "Idempotent" là từ quan trọng: nếu hóa ra tài khoản đã tồn tại, lệnh vẫn thành công và không làm gì cả, thay vì làm hỏng cả lần chuyển.
Lưu ý rằng lệnh tạo này nằm ngoài đề xuất multisig. Tạo tài khoản token cho ai đó không làm dịch chuyển tiền của bạn và không cần kho của bạn cấp quyền, nên nó không thuộc phần mà hai thiết bị của bạn ký. Khoản hoàn phí — thứ thực sự làm dịch chuyển tiền của bạn — thì nằm bên trong đề xuất.
SSP hỗ trợ sẵn những gì
SSP có sẵn SOL gốc, mint USDC chính thức của Circle và FLUX trên Solana. Bất kỳ token SPL nào khác xuất hiện trong kho của bạn cũng được nhận diện và hiển thị bên cạnh chúng.
Có một giới hạn cố ý đáng nói thẳng: các lệnh chuyển Solana của SSP được dựng trên chương trình SPL Token cổ điển. Token phát hành theo Token-2022 — chương trình mới hơn với transfer hook, chuyển khoản bảo mật và các phần mở rộng khác — hiện chưa nằm trong đường gửi. Đây là quyết định về phạm vi chứ không phải sơ suất: các phần mở rộng của Token-2022 có thể thay đổi việc một lệnh chuyển thực sự làm gì, và hỗ trợ chúng nghĩa là phải rà soát từng phần mở rộng đối chiếu với các bảo đảm giải mã trên thiết bị nói ở dưới.
Một lệnh chuyển token thực sự được dựng ra sao
Khi bạn gửi một token SPL từ SSP, giao dịch được ký chứa, theo thứ tự:
- Tạo ATA của người nhận nếu cần — idempotent, do paymaster trả, nằm ngoài đề xuất.
- TransferChecked — chuyển số dư từ tài khoản token của kho bạn sang của người nhận, được kho cấp quyền.
- Hoàn phí cho paymaster — một lệnh chuyển SOL thuần túy từ kho của bạn, nằm trong đề xuất.
Tất cả đáp xuống như một giao dịch nguyên tử duy nhất. Không có bước phê duyệt riêng, không có đề xuất treo lơ lửng trên chuỗi, và không có trạng thái mà tài khoản của người nhận đã được tạo còn lệnh chuyển thì chưa xảy ra. Hoặc toàn bộ thực thi, hoặc không gì cả.
Tài khoản nguồn chính là ATA của kho bạn — dẫn xuất theo cùng cách tất định, với địa chỉ chương trình của kho làm chủ sở hữu. Vì kho là địa chỉ dẫn xuất từ chương trình chứ không phải một cặp khóa, phép dẫn xuất cho phép rõ ràng một chủ sở hữu nằm ngoài đường cong ed25519. Nếu bạn muốn chi tiết nền tảng về việc vì sao địa chỉ kho hoạt động như vậy, multisig Solana tự khởi tạo có bàn tới.
Số thập phân là một phần của chữ ký
Đây là chỗ đáng chậm lại, vì đây là nơi một token có thể nói dối bạn.
Mint khai báo token của nó dùng bao nhiêu chữ số thập phân. USDC dùng sáu; nhiều token dùng chín; không có quy tắc nào cả. Nếu một chiếc ví hiển thị "100 USDC" nhưng lại dựng lệnh chuyển theo một số đơn vị thô giả định sai số thập phân, bạn có thể gửi nhiều gấp nghìn lần mà chẳng thấy gì bất thường trên màn hình.
SSP dùng TransferChecked thay cho lệnh chuyển thuần. Khác biệt là TransferChecked nhúng địa chỉ mint và byte số thập phân thẳng vào dữ liệu lệnh được ký. Từ đó sinh ra ba lớp kiểm tra riêng biệt:
- Tiện ích của bạn giải mã các byte và so với những gì nó đang hiển thị.
- SSP Key giải mã chính các byte ấy một cách độc lập trên điện thoại và so với siêu dữ liệu token do tiện ích cung cấp.
- Chương trình SPL Token trên chuỗi so số thập phân trong lệnh với số thập phân thật của mint và từ chối giao dịch nếu chúng lệch nhau.
Lớp kiểm tra thứ ba là lớp không thể nói vòng vo mà qua được. Một mint khai số thập phân khác với thực tế không tạo ra một lệnh chuyển sai — nó tạo ra một giao dịch thất bại.
Nhận token
Nhận thì đơn giản hơn, chỉ một nếp gấp nhỏ. Hãy đưa cho người gửi địa chỉ ví của bạn — địa chỉ SSP hiện trên màn hình nhận — chứ không phải địa chỉ tài khoản token. Dù họ gửi gì, ATA đúng vẫn được dẫn xuất từ địa chỉ của bạn và mint, và ví của người gửi sẽ tạo nó nếu cần.
Nếu kho của bạn chưa từng giữ token đó, tài khoản sẽ không tồn tại cho tới khi lần chuyển đầu tiên tới nơi, và tiền thuê của nó do người gửi cho bạn trả. Điều này là bình thường và không đòi hỏi gì ở bạn. Nó đồng nghĩa rằng trình khám phá khối sẽ không hiện tài khoản token nào cho một token bạn được hứa nhưng chưa nhận — đó là tài khoản chưa tồn tại, không phải một lệnh chuyển bị mất.
Những cái bẫy thường gặp
Gửi tới địa chỉ tài khoản token thay vì địa chỉ ví. Một số trình khám phá đặt ATA ở vị trí nổi bật. Gửi token tới một tài khoản token thay vì tới chủ của nó là cách mất tiền nổi tiếng trên Solana. SSP mong đợi địa chỉ ví của chủ sở hữu rồi tự dẫn xuất phần còn lại.
Cho rằng một token lạ là an toàn chỉ vì nó hiện trong ví. Ai cũng có thể tạo một mint và gửi cho bạn, và mint có thể mang tên nhái các token thật. Việc một token hiện ra trong kho không phải là sự bảo chứng. Hãy đối chiếu địa chỉ mint với nguồn chính thức trước khi coi một số dư là giá trị thật.
Trông đợi cơ chế phê duyệt kiểu Ethereum. Token SPL có cơ chế ủy quyền, nhưng khuôn mẫu hạn mức thường trực khiến phê duyệt ERC-20 thành rủi ro lặp đi lặp lại không phải là cách phần lớn ứng dụng Solana được xây. Nếu bạn đến từ Ethereum, phê duyệt token: những quyền bạn cứ liên tục cấp giải thích thói quen bạn đang gỡ bỏ, còn Ethereum trong SSP đưa ra phần đối chiếu.
Quên khoản phụ trội của lần gửi đầu. Khoảng ~0,0025 SOL thêm vào ở lần chuyển đầu tiên tới người nhận mới là tiền thuê, không phải khoản phí SSP thu. Nó nằm trong tài khoản token của người nhận và họ lấy lại được nếu sau này đóng tài khoản ấy.
Về cơ chế từng bước của một lệnh chuyển thật, hãy xem gửi Solana bằng SSP. Về cách SSP giữ chính cái kho trong một multisig 2-trên-2 không có người tạo, hãy bắt đầu từ Solana trong SSP.
