Thứ Tư, một loạt người dùng mở ví Ready và nhận thấy thẻ của họ không còn hoạt động. Không có thông báo trước. Không có lỗi bảo mật. Nhà phát hành thẻ Kulipa đã ngừng hoạt động. Founder của Ready, Itamar Lesuisse, viết rằng ông biết tin cùng lúc với người dùng.

Đối với một nhà nghiên cứu bảo mật, đây là loại sự kiện đáng lo nhất. Một hợp đồng thông minh bị exploit có thể được phân tích, vá và rút kinh nghiệm. Một công ty phát hành thẻ đột ngột biến mất thì không. Bạn không thể gửi một giao dịch 'thoát' khỏi mối quan hệ ngân hàng của họ. Bạn không thể chứng minh rằng họ đã vi phạm điều khoản bằng một bằng chứng mật mã. Bạn chỉ có thể đứng nhìn và đợi một nhà phát hành mới xuất hiện.

Vụ việc này không được mô tả là một 'hack'. Nhưng xét về mức độ gián đoạn, nó tương đương với một bridge bị đóng băng: tài sản trên chain vẫn còn, nhưng khả năng sử dụng chúng cho cuộc sống hàng ngày đã biến mất.

Bối cảnh: một chiếc thẻ từ ví tự quản lý

Ready là một ví self-custody, tiền thân là Argent. Ví này chủ yếu hoạt động trên các hệ sinh thái ZKsync và Starknet, nơi người dùng nắm giữ private key và kiểm soát tài sản trực tiếp trên blockchain. Sản phẩm thẻ của Ready không phải là một sản phẩm blockchain. Nó là một sản phẩm ngân hàng: một nhà phát hành thẻ, Kulipa, đứng ra kết nối ví với mạng lưới thanh toán truyền thống. Khi người dùng quẹt thẻ tại một máy POS, Kulipa xử lý giao dịch bằng stablecoin hoặc tiền pháp định, sau đó thanh toán với ngân hàng đối tác và tổ chức thẻ như Visa hoặc Mastercard.

Đây là một mô hình lai. Lớp tài sản thì phi tập trung. Lớp thanh toán thì tập trung. Và khi lớp thanh toán sụp đổ, lớp tài sản vẫn còn đó nhưng trở nên vô dụng với nhu cầu chi tiêu hàng ngày. Đây chính là điểm mấu chốt của toàn bộ sự việc.

Theo báo cáo của The Defiant, không chỉ Ready bị ảnh hưởng. Solflare, một ví phổ biến trên Solana, cũng dùng Kulipa. Các dự án thẻ khác cũng cùng chung số phận. Chỉ trong một đêm, một hạ tầng thanh toán dùng chung cho nhiều hệ sinh thái đã ngừng hoạt động. Sự cố không nằm ở hợp đồng thông minh, không nằm ở validator, không nằm ở consensus. Nó nằm ở một công ty có quan hệ ngân hàng.

Kiến trúc của một chiếc thẻ 'tự quản lý'

Để hiểu vì sao sự kiện này có thể xảy ra, cần tách bạch các lớp trong hệ thống.

Lớp thứ nhất là blockchain. Đây là nơi tài sản thực sự tồn tại. Người dùng có private key, có thể ký giao dịch, có thể chuyển token mà không cần xin phép ai. Lớp này có thể được kiểm toán, có thể được xác minh bằng merkle proof, có thể được mô phỏng trong môi trường testnet.

Lớp thứ hai là ví. Ví giao tiếp với blockchain, xây dựng giao diện, quản lý khóa, xác nhận giao dịch. Ví có thể là mã nguồn mở hoặc đóng, có thể được kiểm tra bởi cộng đồng. Rủi ro ở lớp này thường là lỗi phần mềm, lỗi UX hoặc lỗ hổng trong quá trình ký.

Lớp thứ ba là nhà phát hành thẻ. Đây là một công ty có giấy phép hoặc quan hệ với ngân hàng. Họ nhận yêu cầu từ ví, kiểm tra KYC, kiểm tra số dư, chuyển đổi tài sản thành tiền pháp định hoặc stablecoin và thực hiện thanh toán. Kulipa nằm ở lớp này.

Lớp thứ tư là ngân hàng và mạng lưới thẻ. Họ cung cấp cơ sở hạ tầng thanh toán truyền thống. Một giao dịch thẻ thành công cần sự cho phép của họ.

Trong kiến trúc này, người dùng tự quản lý tài sản ở lớp một, nhưng không thể tự quản lý khả năng chi tiêu ở lớp ba và bốn. Nếu ngân hàng rút lui, nếu nhà phát hành mất giấy phép, nếu mạng lưới thẻ từ chối, chiếc thẻ sẽ chết. Và không có bất kỳ bằng chứng mật mã nào có thể ngăn điều đó xảy ra.

Điều này dẫn đến một nghịch lý. Người dùng chọn ví self-custody vì họ muốn kiểm soát. Nhưng khi họ gắn một chiếc thẻ vào ví, họ đang phó thác một phần quan trọng của trải nghiệm tài chính cho một thực thể pháp lý mà họ không thể kiểm tra.

Vì sao Kulipa lại quan trọng đến vậy?

Kulipa không phải là một cái tên nổi tiếng. Nhưng nó nằm ở vị trí trung tâm trong một mạng lưới các ví. Khi Kulipa ngừng hoạt động, tất cả các ví dựa vào nó đều mất khả năng phát hành và vận hành thẻ. Đây là một ví dụ kinh điển về single point of failure trong lớp hạ tầng off-chain.

Trong vài năm qua, ngành công nghiệp tiền mã hóa đã quen với việc phát hiện các điểm lỗi tập trung trên blockchain: một bridge bị hack, một protocol bị exploit, một admin key bị lộ. Những sự cố này có thể được phát hiện bằng cách đọc code, kiểm tra quyền, mô phỏng tấn công. Nhưng điểm lỗi của Kulipa nằm ngoài phạm vi đó. Nó nằm trong một hợp đồng pháp lý, trong một mối quan hệ ngân hàng, trong một bảng cân đối kế toán. Bạn không thể đọc source code của một ngân hàng để biết họ sắp chấm dứt quan hệ với Kulipa.

Nhìn từ góc độ cấu trúc, Kulipa giống như một oracle trong hệ thống DeFi. Nó cung cấp một nguồn thông tin quan trọng: khả năng nối blockchain với thế giới tài chính truyền thống. Nhưng oracle này không có cơ chế kiểm soát phi tập trung. Nó không có bằng chứng để xác minh. Và khi oracle ngừng hoạt động, toàn bộ các hợp đồng phía trên trở nên vô dụng.

Sự kiện này cho thấy một điều quan trọng: trong một hệ thống lai, độ bảo mật của toàn bộ hệ thống được quyết định bởi lớp yếu nhất. Lớp yếu nhất ở đây không phải blockchain, không phải ví, mà là mối quan hệ giữa nhà phát hành thẻ và ngân hàng. Đây là lớp ngoài chain, nơi không có cơ chế đồng thuận nào có thể bảo vệ bạn.

Kiểm toán không thể cứu bạn

Tôi đã làm kiểm toán smart contract nhiều năm. Khi tôi nhận một hợp đồng để audit, tôi thường tìm kiếm các điều kiện có thể khiến hệ thống dừng hoạt động: một hàm có thể bị revert, một biến có thể bị gán sai, một phase có thể bị kẹt. Tôi tìm cách khai thác, tìm cách kích hoạt lỗi, tìm cách vượt qua kiểm tra quyền. Nhưng vụ sập thẻ Ready khiến tôi nhận ra rằng có một loại lỗi mà kiểm toán thông thường không thể chạm tới.

Năm 2024, tôi tham gia audit một module proof verification trong zkSync Era. Tôi phát hiện một lỗi logic trong batch proof: một điều kiện bị thiếu có thể cho phép chấp nhận một proof không hợp lệ. Lỗi này có thể được mô tả chính xác trong một báo cáo, có thể tái hiện bằng một kịch bản tấn công cụ thể, và có thể được vá bằng một thay đổi trong mã nguồn. Đó là một lỗi 'cứng', một lỗi có thể được chứng minh.

Ngược lại, lỗi của Kulipa là một lỗi 'mềm'. Nó không nằm trong code, nó nằm trong vận hành doanh nghiệp. Có thể Kulipa mất một ngân hàng đối tác. Có thể họ gặp vấn đề thanh khoản. Có thể họ bị áp lực từ cơ quan quản lý. Bất kể nguyên nhân là gì, bạn không thể phát hiện nó bằng fuzzing. Bạn không thể phát hiện nó bằng formal verification. Bạn không thể phát hiện nó bằng cách mô phỏng một kẻ tấn công, vì kẻ tấn công ở đây có thể là chính đối tác ngân hàng hoặc cơ quan quản lý.

Với một smart contract, bạn có thể đặt câu hỏi: 'Nếu admin key bị lộ, điều gì xảy ra?' Với một nhà phát hành thẻ, bạn phải đặt câu hỏi: 'Nếu công ty này đóng cửa sau một đêm, điều gì xảy ra?' Câu hỏi này nằm ngoài phạm vi của một báo cáo audit. Nó nằm trong phạm vi của kế hoạch kinh doanh và đánh giá rủi ro đối tác.

Tôi không nói rằng audit là vô ích. Tôi nói rằng audit chỉ bao phủ một phần của bề mặt rủi ro. Cộng đồng tiền mã hóa thường có thói quen tin rằng một dự án có audit là an toàn. Điều đó đúng với lớp smart contract. Nhưng với một sản phẩm kết nối tài chính truyền thống, audit không thể xác nhận rằng các đối tác bank của bạn ổn định. Đây là một mù quáng hệ thống.

Số dư thẻ: vùng tối chưa được làm rõ

Theo công bố của Ready, tiền của người dùng không bị ảnh hưởng. Tôi tin điều đó, nhưng tôi muốn đặt câu hỏi: 'người dùng' ở đây là ai và 'tiền' ở đây là gì?

Trong một ví self-custody, tài sản nằm trên blockchain. Khi Kulipa đóng cửa, blockchain không biết Kulipa tồn tại. Do đó, tài sản trên chuỗi không thể bị ảnh hưởng. Nhưng nhiều thẻ tín dụng hoặc thẻ trả trước cho phép người dùng nạp tiền vào một tài khoản nội bộ của nhà phát hành. Số dư đó không nằm trên blockchain. Nó nằm trong một cơ sở dữ liệu của Kulipa. Nếu cơ sở dữ liệu đó ngừng hoạt động, ai có thể đảm bảo rằng số dư sẽ được hoàn trả?

Trong các sản phẩm thẻ self-custody điển hình, có hai hình thức. Hình thức thứ nhất là thẻ debit liên kết trực tiếp với tài sản trên ví. Mỗi giao dịch sẽ ký một hợp đồng thông minh để chuyển tiền. Hình thức này an toàn hơn vì không có số dư nội bộ. Hình thức thứ hai là thẻ trả trước. Người dùng chuyển tiền vào một tài khoản của nhà phát hành, nhà phát hành ghi nợ vào tài khoản đó khi chi tiêu. Hình thức này có rủi ro đối tác rõ ràng.

Theo báo cáo của The Defiant, không có thông tin chi tiết về việc liệu Ready sử dụng hình thức nào. Nếu người dùng chỉ dùng thẻ debit trực tiếp, thì câu nói 'funds are safe' hoàn toàn chính xác. Nhưng nếu có bất kỳ ai nạp tiền vào một tài khoản thẻ trả trước, họ có thể đang đối mặt với một khoản nợ khó đòi.

Đây là một vùng tối trong báo cáo của The Defiant, và cũng là một vùng tối trong ngành công nghiệp thẻ crypto nói chung. Người dùng thường không phân biệt được đâu là tài sản trên blockchain và đâu là số dư trong sổ cái của nhà phát hành. Ngay cả khi UI hiển thị 'balance', nó không cho biết balance đó nằm ở đâu.

Tôi khuyến nghị một câu hỏi đơn giản cho bất kỳ ai dùng thẻ self-custody: 'Nếu nhà phát hành thẻ biến mất vào ngày mai, tôi có mất gì không?' Nếu câu trả lời là 'không', bạn đang dùng một sản phẩm thực sự an toàn. Nếu câu trả lời là 'tôi không chắc', bạn đang nắm giữ rủi ro tín dụng mà bạn không thể đo lường.

Vì sao các ví dùng chung một nhà phát hành?

Một câu hỏi tự nhiên là: vì sao Ready và Solflare không dùng các nhà phát hành khác nhau? Vì sao họ cùng phụ thuộc vào một Kulipa?

Câu trả lời nằm ở chi phí và quy mô. Để phát hành thẻ, một công ty cần có giấy phép, cần quan hệ với ngân hàng, cần tuân thủ KYC/AML, cần kết nối với mạng lưới thẻ. Đây là những chi phí cố định lớn. Một ví nhỏ không thể tự mình xây dựng hạ tầng này. Họ chọn một nhà phát hành trung gian đã có sẵn mọi thứ. Điều này tạo ra một thị trường tập trung vào một vài nhà phát hành.

Hệ quả là nếu một nhà phát hành gặp sự cố, toàn bộ hệ sinh thái khách hàng của họ bị ảnh hưởng. Đây giống như mô hình các nhà cung cấp dịch vụ đám mây: nhiều công ty dùng chung AWS, và khi AWS sập, hàng loạt dịch vụ sập theo. Nhưng trong thế giới blockchain, nơi khái niệm 'phi tập trung' được đề cao, sự phụ thuộc vào một nhà phát hành thẻ duy nhất là một kiểu 'centralization' mà nhiều người bỏ qua.

Từ góc độ kinh tế, các ví có thể không có đủ động lực để xây dựng dự phòng. Dự phòng đòi hỏi chi phí cao, trong khi xác suất sự cố có vẻ thấp. Nhưng khi sự cố xảy ra, mức độ thiệt hại là lớn. Đây là một vấn đề kinh điển trong quản lý rủi ro: chi phí phòng ngừa có vẻ cao nhưng nhỏ hơn nhiều so với chi phí của thảm họa.

Có một điểm thú vị: trong các hệ thống blockchain, người ta thường chấp nhận trả phí cao để có tính phi tập trung. Nhưng với thẻ, người ta lại chấp nhận rủi ro tập trung để tiết kiệm chi phí. Sự không nhất quán này là một trong những lý do khiến sự kiện Kulipa trở nên đáng giá để nghiên cứu.

Tác động hệ sinh thái: nhiều hơn một chiếc thẻ bị hỏng

Sự kiện này không chỉ ảnh hưởng đến người dùng Ready. Nó ảnh hưởng đến toàn bộ câu chuyện về 'crypto card' như một cầu nối giữa tiền mã hóa và cuộc sống thực.

Trong những năm qua, các dự án thẻ thường quảng bá rằng họ giúp người dùng 'chi tiêu tiền mã hóa ở bất cứ đâu'. Đây là một câu chuyện hấp dẫn. Nhưng vụ Kulipa cho thấy câu chuyện đó bỏ qua một chi tiết quan trọng: việc chi tiêu phụ thuộc vào một công ty trung gian, và công ty đó có thể biến mất mà không cần báo trước.

Điều này tạo ra một sự thay đổi trong nhận thức. Người dùng sẽ không còn hỏi 'thẻ có hỗ trợ token nào' hay 'phí là bao nhiêu'. Họ sẽ hỏi 'ai phát hành thẻ' và 'điều gì xảy ra nếu nhà phát hành sụp đổ'. Những câu hỏi này từng chỉ được các nhà đầu tư tổ chức đặt ra, nhưng giờ đây chúng trở thành câu hỏi chính đáng của người dùng cuối.

Solflare bị ảnh hưởng cũng là một tín hiệu cho hệ sinh thái Solana. Solana vốn nổi tiếng với tốc độ và chi phí thấp, và nhiều người dùng kỳ vọng rằng nó có thể trở thành nền tảng cho thanh toán. Nhưng sự phụ thuộc vào Kulipa cho thấy rằng một chiếc thẻ trên Solana vẫn có thể bị tê liệt bởi một sự cố off-chain. Điều này không phải lỗi của Solana, nhưng nó làm giảm sức hấp dẫn của câu chuyện 'Solana là mạng thanh toán'.

Đối với các ví khác, đây là một lời cảnh báo. Nếu ví của bạn có thẻ, bạn cần biết ai là nhà phát hành. Nếu nhà phát hành đó không có kế hoạch dự phòng, bạn nên coi thẻ như một tính năng thử nghiệm, không phải một sản phẩm ổn định. Tôi kỳ vọng rằng trong 3-6 tháng tới, nhiều ví sẽ bắt đầu quảng bá 'multi-issuer support' như một tiêu chí lựa chọn. Điều này có thể đẩy chi phí lên cao, nhưng đó là cái giá của sự ổn định.

Góc nhìn phản trực giác: self-custody không thất bại, mà mới chỉ hoàn thành một nửa

Có một cách đọc sai về sự kiện này: đó là coi nó như một minh chứng rằng self-custody không hoạt động, rằng người dùng vẫn cần một bên trung gian đáng tin cậy. Tôi cho rằng điều này hoàn toàn sai.

Self-custody hoạt động. Tài sản của người dùng trên blockchain không bị mất. Không ai có thể lấy đi private key. Vấn đề không nằm ở self-custody, mà nằm ở một nửa self-custody: bạn tự quản lý tài sản, nhưng bạn thuê ngoài 'lối ra fiat' cho một công ty. Khi công ty đó sụp đổ, bạn vẫn có tài sản, nhưng bạn không có lối ra.

Điều này tương tự như việc xây một ngôi nhà kiên cố nhưng chỉ có một cây cầu duy nhất dẫn ra ngoài. Ngôi nhà không sụp đổ, nhưng nếu cây cầu bị sập, bạn bị mắc kẹt. Bạn không thể đổ lỗi cho ngôi nhà. Bạn phải thiết kế lại hệ thống giao thông.

Trong blockchain, chúng ta thường nói 'don't trust, verify'. Nguyên tắc này đúng với các dữ liệu trên chain. Bạn có thể verify một giao dịch, verify một state root, verify một proof. Nhưng bạn không thể verify một quan hệ ngân hàng. Bạn không thể verify rằng ngân hàng đối tác của Kulipa sẽ không rút lui vào tuần tới. Điều đó nằm ngoài khả năng của công nghệ blockchain hiện tại.

Vì vậy, thông điệp thực sự của sự kiện này là: đừng gọi một chiếc thẻ gắn với ví self-custody là 'phi tập trung'. Nó phi tập trung ở phần tài sản, nhưng tập trung ở phần thanh toán. Nếu bạn chấp nhận sự tập trung đó, hãy chấp nhận rủi ro đi kèm.

Có một điểm phản trực giác nữa: sự kiện này có thể tốt cho ngành trong dài hạn. Nó phơi bày một rủi ro hệ thống mà trước đây ít người thấy. Khi rủi ro được thấy rõ, các bên liên quan có thể hành động. Các ví sẽ đa dạng hóa nhà phát hành. Các nhà phát hành sẽ minh bạch hơn về tình trạng quan hệ ngân hàng. Người dùng sẽ hỏi những câu hỏi đúng đắn hơn. Đây là quá trình trưởng thành của một ngành công nghiệp.

Nhưng quá trình đó không xảy ra tự nhiên. Nó đòi hỏi sự thay đổi trong cách thiết kế sản phẩm. Các ví muốn cung cấp thẻ cần phải mô hình hóa rủi ro nhà phát hành giống như họ mô hình hóa rủi ro smart contract. Họ cần có kịch bản khẩn cấp: nếu issuer A ngừng hoạt động, chuyển sang issuer B như thế nào? Người dùng có cần đăng ký lại không? Số dư có được di chuyển không? Những câu hỏi này chưa từng xuất hiện trong whitepaper của hầu hết các ví.

Điểm mù bảo mật: continuity planning

Trong bảo mật thông tin, có một khái niệm gọi là business continuity. Nó không hỏi 'làm sao để ngăn chặn tấn công', mà hỏi 'nếu sự cố xảy ra, làm sao để tiếp tục hoạt động'. Hầu hết các dự án crypto đều có disaster recovery cho hạ tầng blockchain của họ, nhưng rất ít dự án có kế hoạch tương tự cho các đối tác off-chain.

Kulipa ngừng hoạt động là một sự cố về continuity. Nhưng nó không được xử lý như một sự cố bảo mật. Nó được xử lý như một tin tức kinh doanh. Đây là một sai lầm trong nhận thức.

Một nhà phát hành thẻ là một phần của đường dẫn thanh toán. Nếu đường dẫn bị đứt, người dùng không thể chi tiêu. Điều này giống hệt một cuộc tấn công DoS vào smart contract. Nhưng vì đường dẫn nằm ngoài chain, các công cụ giám sát blockchain không thể phát hiện ra. Bạn cần một hệ thống giám sát khác: theo dõi quan hệ ngân hàng của đối tác, theo dõi các thay đổi pháp lý, theo dõi sức khỏe tài chính.

Trong một thế giới lý tưởng, mỗi ví sẽ có một bảng điều khiển theo dõi tình trạng của từng nhà phát hành thẻ. Bảng điều khiển này có thể bao gồm: ngày ký hợp đồng, ngày hết hạn, quốc gia cấp phép, danh sách ngân hàng đối tác, lịch sử sự cố. Nhưng hiện tại, các dữ liệu này không tồn tại dưới dạng công khai. Và ngay cả khi tồn tại, chúng cũng không được chuẩn hóa.

Tôi nghi ngờ rằng trong tương lai, sẽ xuất hiện các dịch vụ rating cho nhà phát hành thẻ, tương tự như Moody's cho trái phiếu. Họ sẽ phân tích báo cáo tài chính, đánh giá quan hệ ngân hàng, đưa ra xếp hạng tín dụng. Nhưng trước khi điều đó xảy ra, người dùng chỉ có thể tự bảo vệ bằng cách giữ số dư thẻ thấp và luôn có phương án dự phòng.

Vụ Kulipa so với các vụ sập cầu nối

Nếu bạn đã từng chứng kiến một bridge bị hack, bạn sẽ thấy một sự tương đồng. Trong một bridge, tài sản của người dùng bị khóa trong một hợp đồng thông minh và phụ thuộc vào các validator. Khi validator bị tấn công hoặc bị kiểm soát, tài sản có thể bị rút. Trong vụ Kulipa, tài sản không bị mất, nhưng khả năng sử dụng bị đóng băng. Sự tương đồng nằm ở chỗ: cả hai đều là các lớp trung gian giữa hai hệ thống.

Có một khác biệt quan trọng. Khi một bridge bị hack, cộng đồng có thể phân tích mã nguồn, tìm ra lỗ hổng, thiết kế giải pháp mới. Khi một nhà phát hành thẻ đóng cửa, bạn không có gì để phân tích. Bạn chỉ có thể chờ đợi và hy vọng rằng một nhà phát hành khác sẽ thay thế.

Điều này dẫn đến một câu hỏi lớn hơn: liệu có thể xây dựng một lớp thanh toán phi tập trung thực sự, không phụ thuộc vào ngân hàng? Hiện tại, câu trả lời là không. Các mạng lưới thanh toán truyền thống, KYC/AML, và quy định ngân hàng tạo ra những rào cản không thể vượt qua bằng công nghệ mã hóa đơn thuần. Vì vậy, bất kỳ sản phẩm thẻ nào cũng sẽ chứa một lõi tập trung.

Nhưng điều đó không có nghĩa là không thể giảm rủi ro. Một lớp thanh toán có thể được thiết kế với nhiều nhà phát hành, nhiều ngân hàng, nhiều mạng lưới. Nếu một mắt xích gãy, hệ thống vẫn có thể chuyển sang mắt xích khác. Đây là cách mà internet hoạt động: nhiều đường kết nối, nhiều nhà cung cấp, tự động định tuyến lại.

Dấu hiệu sớm của một vấn đề mang tính hệ thống

Tôi muốn đặt một câu hỏi: Kulipa có phải là trường hợp duy nhất không?

Trong ngành thanh toán crypto, có rất nhiều nhà phát hành thẻ hoạt động thầm lặng. Một số có quan hệ ngân hàng tốt, một số thì không. Mô hình kinh doanh của họ phụ thuộc vào phí giao dịch, phí thường niên, và chênh lệch tỷ giá. Khi thị trường tiền mã hóa giảm, khối lượng chi tiêu giảm, doanh thu giảm, trong khi chi phí tuân thủ vẫn cao. Đây là một môi trường khắc nghiệt.

Nếu một nhà phát hành đóng cửa, những nhà phát hành khác có thể bị ảnh hưởng gián tiếp. Các ngân hàng đối tác có thể trở nên thận trọng hơn, yêu cầu thêm tài sản thế chấp, tăng phí, hoặc chấm dứt hợp đồng với các nhà phát hành crypto. Điều này có thể dẫn đến một hiệu ứng domino.

Do đó, tôi sẽ không ngạc nhiên nếu trong 3-6 tháng tới, có thêm một hoặc hai nhà phát hành thẻ crypto ngừng hoạt động. Nếu điều đó xảy ra, thị trường sẽ phải đối mặt với một cuộc khủng hoảng niềm tin vào khái niệm crypto card. Người dùng sẽ rút khỏi các sản phẩm này, và các ví sẽ phải chi tiền để xây dựng hạ tầng dự phòng.

Nhưng cũng có một kịch bản tích cực. Sự kiện Kulipa có thể là một lời cảnh tỉnh. Các ví có thể chủ động đa dạng hóa nhà phát hành ngay bây giờ, trước khi có thêm sự cố. Họ có thể công bố rõ ràng 'chúng tôi hỗ trợ nhiều nhà phát hành, nếu một bên gặp sự cố, thẻ của bạn vẫn hoạt động với bên khác'. Điều này có thể trở thành một lợi thế cạnh tranh.

Bài học cho người dùng

Nếu bạn đang dùng một chiếc thẻ của ví self-custody, tôi có vài lời khuyên. Đầu tiên, hãy xác định nhà phát hành thẻ. Đừng chỉ nhìn vào thương hiệu ví. Tìm hiểu xem ví dùng ai để phát hành thẻ, và liệu họ có kế hoạch dự phòng không. Nếu thông tin này không có trên trang web, hãy hỏi đội ngũ hỗ trợ.

Thứ hai, đừng nạp quá nhiều tiền vào thẻ. Nếu thẻ là loại trả trước, hãy nạp đủ cho nhu cầu chi tiêu gần nhất. Số dư lớn trong tài khoản thẻ không được bảo vệ bởi blockchain. Nó là tiền gửi tại một công ty tư nhân.

Thứ ba, hãy có một kế hoạch dự phòng. Nếu thẻ của bạn ngừng hoạt động, bạn có thể sử dụng một ví khác, một sàn giao dịch, hoặc một dịch vụ chuyển tiền khác. Đừng đặt toàn bộ cuộc sống tài chính vào một chiếc thẻ.

Thứ tư, hãy ưu tiên những ví thực sự tự quản lý tài sản và có kiến trúc cho phép chuyển đổi nhà phát hành một cách linh hoạt. Đó là một đặc điểm kỹ thuật hiếm có, nhưng nó xứng đáng để trả thêm phí.

Bài học cho nhà phát triển

Các nhà phát triển ví cần phải coi nhà phát hành thẻ như một phần của threat model. Điều này có nghĩa là họ cần phải dự phòng kép, kiểm tra sức khỏe đối tác định kỳ, và có một kế hoạch chuyển đổi rõ ràng khi đối tác gặp sự cố.

Cụ thể, hợp đồng với nhà phát hành nên có các điều khoản yêu cầu thông báo trước khi ngừng dịch vụ. Nếu không thể thương lượng, hãy xây dựng một cơ chế phát hiện sớm: theo dõi các thay đổi trên trang web của đối tác, theo dõi các tin tức pháp lý, theo dõi trạng thái API. Nếu API bắt đầu lỗi, nếu thời gian phản hồi tăng lên, đó có thể là dấu hiệu sớm của sự cố.

Hơn nữa, các ví nên thiết kế một lớp abstraction giữa sản phẩm thẻ và nhà phát hành. Thay vì gọi trực tiếp API của một issuer, họ có thể định nghĩa một interface chung. Khi cần chuyển issuer, họ chỉ cần cài một module mới. Người dùng không cần đăng ký lại, không cần thay đổi số thẻ. Điều này khó, nhưng không phải là không thể.

Trong một hệ thống lý tưởng, người dùng nên có một địa chỉ thanh toán ổn định, không phụ thuộc vào bất kỳ nhà phát hành nào. Ví dụ, một mã QR chứa địa chỉ blockchain và một danh sách các nhà phát hành được hỗ trợ. Khi người dùng quẹt thẻ, hệ thống tự động chọn nhà phát hành có sẵn. Điều này giống như cách mà TCP/IP định tuyến lại khi một nút mạng bị lỗi.

Nhưng hiện tại, chúng ta còn rất xa điều đó.

Vai trò của quy định

Có một cách giải thích cho sự kiện Kulipa: cơ quan quản lý đã siết chặt hoặc ngân hàng đối tác không muốn tiếp tục hợp tác. Dù lý do là gì, nó cho thấy rằng trong lĩnh vực thanh toán, quy định có thể tác động mạnh hơn bất kỳ lỗ hổng kỹ thuật nào.

Điều này tạo ra một nghịch lý. Các dự án crypto thường tìm cách tránh quy định để linh hoạt. Nhưng sản phẩm thẻ cần quy định để tồn tại. Một nhà phát hành không có giấy phép sẽ không được ngân hàng chấp nhận. Một nhà phát hành có giấy phép nhưng hoạt động trong một khu vực pháp lý không chắc chắn sẽ luôn đối mặt với rủi ro.

Sự kiện Kulipa có thể khiến các nhà phát hành khác thận trọng hơn trong việc mở rộng. Họ sẽ tập trung vào một vài thị trường lớn, ưu tiên các ngân hàng có uy tín. Điều này có thể làm giảm sự đa dạng và tăng chi phí, nhưng nó sẽ cải thiện độ ổn định.

Một câu hỏi cuối

Sự cố Kulipa không phải là một sự cố blockchain. Nó là một sự cố của thế giới thực xâm nhập vào thế giới crypto. Nó nhắc chúng ta rằng không phải mọi thứ đều có thể được giải quyết bằng hợp đồng thông minh. Có những rủi ro nằm ngoài phạm vi mã nguồn, ngoài phạm vi merkle tree, ngoài phạm vi zero-knowledge proof.

ZK proof im lặng nhưng vạn lời. Nó chứng minh mà không tiết lộ. Nhưng một công ty phát hành thẻ im lặng không phải là một bằng chứng. Nó chỉ là một cánh cửa đóng sập mà không có lý do được công bố.

Trong quá trình kiểm toán, tôi học được rằng điều quan trọng nhất không phải là tìm ra lỗi, mà là hiểu được giới hạn của những gì bạn có thể biết. Sự kiện Kulipa cho thấy một giới hạn rõ ràng: bạn có thể kiểm toán mọi dòng code, bạn có thể xác minh mọi giao dịch, nhưng bạn không thể kiểm toán một mối quan hệ ngân hàng.

Vì vậy, khi chọn một ví self-custody, đừng chỉ hỏi về công nghệ. Hãy hỏi về các mối quan hệ. Hãy hỏi điều gì xảy ra nếu một mối quan hệ đó biến mất.

Câu trả lời sẽ cho bạn biết ví đó thực sự đáng tin đến đâu.

Một transaction, cả một câu chuyện. Nhưng với chiếc thẻ Ready, toàn bộ câu chuyện là sự im lặng của một nhà phát hành.

Trong 6 tháng tới, tôi sẽ theo dõi xem có bao nhiêu ví bắt đầu quảng bá 'đa nhà phát hành' như một tính năng. Nếu không có, sự kiện này sẽ chỉ là một ghi chú trong lịch sử. Nếu có, nó sẽ trở thành một bước ngoặt.

Tôi đặt cược vào điều thứ hai.

Vì khi một hệ thống gãy ở một điểm, bạn không sửa điểm đó. Bạn thiết kế lại toàn bộ.