Một địa chỉ ví trông có vẻ đơn giản: một chuỗi ký tự bạn sao chép, dán và gửi tiền tới. Trên Bitcoin, nó gần như đúng là đơn giản như vậy. Trên Solana, đặt một ví dùng chung — một multisig — phía sau một địa chỉ lại khó một cách đáng ngạc nhiên. Bài viết này giải thích vì sao, và đặt ra câu hỏi mà phần còn lại của loạt bài này sẽ trả lời.
Một địa chỉ multisig phải hứa hẹn điều gì
Ví multisig là ví được kiểm soát bởi nhiều khóa, trong đó một số lượng cố định trong số đó phải đồng ý trước khi tiền được di chuyển. Một multisig "2 trong 3", chẳng hạn, có ba khóa và cần bất kỳ hai khóa nào phê duyệt một khoản thanh toán. Mục đích là loại bỏ các điểm hỏng đơn lẻ: bạn mất một khóa, hoặc một khóa bị đánh cắp, mà tiền của bạn vẫn an toàn.
Để điều đó hữu ích, địa chỉ phải giữ hai lời hứa. Thứ nhất, nó phải biết được trước — bạn muốn đưa cho ai đó một địa chỉ nạp tiền trước khi bạn hoàn tất mọi thiết lập. Thứ hai, nó phải trung thực: bất kỳ ai gửi tiền tới địa chỉ đó đều phải có thể tin rằng chỉ nhóm khóa đã thỏa thuận, theo quy tắc đã thỏa thuận, mới có thể chi tiêu từ đó. Hãy ghi nhớ hai lời hứa này. Chúng là sợi chỉ xuyên suốt mọi điều bên dưới.
Trên Bitcoin, địa chỉ chính là quy tắc
Bitcoin làm cho việc này trông dễ dàng. Một multisig Bitcoin được mô tả bằng một script nhỏ: danh sách các khóa công khai cộng với quy tắc "M trong N". Để có địa chỉ, bạn lấy script đó và băm (hash) nó. Địa chỉ (một địa chỉ P2WSH) theo đúng nghĩa đen chính là giá trị băm của các quy tắc chi tiêu.
Điều đó có một hệ quả mạnh mẽ một cách lặng lẽ. Bất kỳ ai cũng có thể tính địa chỉ ngoại tuyến, trên một máy tính xách tay không có internet, trước khi phát đi dù chỉ một giao dịch. Không có bước "tạo ví" — ví không cần tồn tại trên mạng để nhận tiền. Script chỉ được tiết lộ về sau, khi tiền được chi, và mạng kiểm tra rằng script được tiết lộ khớp với địa chỉ và có đủ chữ ký hợp lệ. Địa chỉ biết được trước: có. Trung thực: có — vì địa chỉ được dẫn xuất từ chính quy tắc, một tập khóa khác sẽ tạo ra một địa chỉ khác.
Trên Solana, một địa chỉ là một tài khoản phải được tạo ra
Solana hoạt động khác. Trên Solana, mọi thứ đều là một tài khoản — một ô lưu trữ on-chain có chủ sở hữu. Tiền của bạn nằm trong các tài khoản, các chương trình nằm trong các tài khoản, và cấu hình của một multisig cũng nằm trong một tài khoản. Quan trọng là tài khoản không tự nhiên xuất hiện miễn phí. Một tài khoản phải được tạo và trả phí một cách rõ ràng: ai đó cấp vốn cho nó bằng một lượng nhỏ SOL gọi là "tiền thuê" (rent) để mạng lưu trữ dữ liệu của nó.
Do đó, một multisig trên Solana không chỉ là một địa chỉ — nó là một tài khoản do chương trình kiểm soát, chứa danh sách thành viên và ngưỡng. Và tài khoản đó phải được tạo bằng một giao dịch trước khi multisig có thể làm bất cứ điều gì. Đây là gốc rễ của sự khó khăn: một ví dùng chung trên Solana có một bước thiết lập mà Bitcoin đơn giản là không có.
PDA: những địa chỉ không có khóa riêng tư
Solana quả thật có một công cụ thanh lịch cho việc này, gọi là Program Derived Address, hay PDA. Một địa chỉ Solana thông thường có một khóa riêng tư tương ứng — ai giữ khóa thì kiểm soát địa chỉ. Một PDA được xây dựng một cách có chủ đích để nằm ngoài đường cong: đó là một địa chỉ trông hợp lệ nhưng không có khóa riêng tư nào tồn tại và không thể tồn tại. Không ai có thể ký thay nó một cách cá nhân.
Thay vào đó, một PDA được dẫn xuất một cách tất định. Bạn lấy một vài giá trị đầu vào — gọi là "hạt giống" (seeds) — cộng với ID của một chương trình, đưa chúng qua một hàm một chiều, và đầu ra là địa chỉ. Cùng những hạt giống đó và cùng chương trình đó luôn tạo ra cùng một PDA, nên bất kỳ ai cũng có thể tái tạo nó. Và vì không có khóa riêng tư, chỉ chương trình sở hữu mới có thể cho phép các hành động đối với địa chỉ đó, điều nó thực hiện thông qua một cơ chế gọi là lệnh gọi liên chương trình với invoke_signed: chương trình trình các hạt giống cho môi trường chạy của Solana, và môi trường chạy cấp cho nó quyền ký cho PDA. Không bao giờ có một chữ ký mật mã nào được tạo ra — quyền hành động đến từ việc biết các hạt giống, chứ không phải từ việc nắm giữ một khóa.
Một PDA chính là ngôi nhà phù hợp cho một multisig: một địa chỉ được kiểm soát bởi logic của chương trình thay vì bởi bất kỳ một cá nhân nào. Đến đây thì ổn. Phần khó là chọn cái gì làm hạt giống.
Vấn đề cấp vốn trước khi tạo
Đây là chỗ những multisig chiếm ưu thế trên Solana gặp rắc rối. Khác với mô hình tất định của Bitcoin, các multisig được dùng rộng rãi nhất của Solana — Squads V4 là ví dụ dẫn đầu, trưởng thành và được kiểm toán kỹ — dẫn xuất địa chỉ của multisig từ một giá trị ngẫu nhiên vừa được sinh ra và được chọn tại thời điểm tạo, chứ không từ tập thành viên. Trong Squads V4 giá trị đó được gọi là create_key, một khóa thoáng qua được tạo ra khi một người tạo chạy giao dịch tạo.
Dẫn xuất địa chỉ từ một create_key ngẫu nhiên là một lựa chọn thiết kế có chủ đích và hợp lý — nó né được một trường hợp biên khó chịu khi hai nhóm khác nhau muốn đúng cùng một thành phần thành viên. Nhưng nó có hai hệ quả đáng để hiểu rõ:
- Bạn không thể biết địa chỉ trước. Hạt giống không tồn tại cho đến khi ai đó chạy giao dịch tạo, nên địa chỉ cũng vậy. Không có cách nào in ra một địa chỉ nạp tiền và cấp vốn cho nó trước khi thiết lập — vấn đề cấp vốn trước khi tạo. Lời hứa thứ nhất bị phá vỡ.
- Người tạo là một điểm tin cậy đơn lẻ lúc thiết lập. Một tài khoản cụ thể phải chạy giao dịch tạo đó và chọn giá trị ngẫu nhiên đó. Trong khoảng thời gian ngắn của việc thiết lập, bạn tin tưởng bên đó làm đúng.
Không điều nào trong số này khiến Squads V4 kém an toàn — đó là multisig được thử thách nhiều nhất trên Solana và bảo vệ những khoản tiền rất lớn. Nó chỉ đơn giản là một hình dạng khác của niềm tin so với Bitcoin. Địa chỉ không còn là "giá trị băm của quy tắc"; nó là "bất cứ thứ gì giao dịch tạo đã tạo ra".
Ethereum đã tìm ra một con đường trung dung
Ethereum đối mặt với một vấn đề tương tự và đáp lại bằng một tính năng gọi là CREATE2. Nó cho phép bạn tính địa chỉ của một hợp đồng thông minh trước khi hợp đồng được triển khai, từ các đầu vào cố định. Những ví như Safe dùng điều này để cho bạn một thứ gọi là địa chỉ phản thực tế: một địa chỉ thật, có thể cấp vốn, mà bạn có thể chia sẻ và nhận tiền vào đó, trong khi hợp đồng thực sự được triển khai một cách trì hoãn — chỉ khi tiền lần đầu cần di chuyển. Tiêu chuẩn trừu tượng hóa tài khoản mới hơn, ERC-4337, chính thức hóa cùng ý tưởng đó. Nhờ vậy Ethereum lấy lại lời hứa "biết được trước" dù, giống như Solana, cuối cùng nó vẫn cần một đối tượng on-chain tồn tại.
Câu hỏi mà loạt bài này trả lời
Hãy đặt ba mô hình cạnh nhau. Bitcoin: địa chỉ là giá trị băm của quy tắc — biết được ngoại tuyến, trung thực do cấu trúc, không có bước tạo. Ethereum: một địa chỉ phản thực tế — biết được trước, với việc triển khai bị hoãn lại. Các multisig đa năng của Solana: địa chỉ đến từ tính ngẫu nhiên ở thời điểm tạo — không biết được trước, với một người tạo cần được tin tưởng lúc thiết lập.
Vậy đây là câu hỏi. Solana cần các tài khoản, và tài khoản cần được tạo — điều đó sẽ không biến mất. Nhưng liệu một multisig của Solana có bắt buộc phải từ bỏ tính chất của Bitcoin không? Liệu địa chỉ có thể thay vào đó được dẫn xuất thuần túy từ tập thành viên và ngưỡng — chính là quy tắc — để nó biết được ngoại tuyến, có thể cấp vốn trước khi thiết lập, và trung thực vì một nhóm khóa khác sẽ tạo ra một địa chỉ khác?
Đó chính xác là tính chất mà đội ngũ SSP đã xây dựng vào chương trình multisig Solana của riêng họ. Bài viết tiếp theo cho thấy cách làm: một địa chỉ chính là tập thành viên, một kho tiền bạn có thể cấp vốn trước khi bất cứ thứ gì được đăng ký on-chain, và một bước đăng ký không cần đến người tạo nào cả. Thiết kế được phát hành cùng với hỗ trợ Solana trong SSP Wallet — xem thông báo phát hành — và, đúng với cách SSP đối xử với bảo mật, chương trình hiện chỉ ở devnet và đang chờ một cuộc kiểm toán bên ngoài trước khi lên mainnet. Nếu bản thân multisig vẫn còn mới với bạn, hãy bắt đầu với multisig là gì và vì sao nó quan trọng; nếu không, hãy đọc tiếp.
