Tuần này tôi đã làm xong nhiệm vụ trên CreatorPad cho @Dusk , và điều đọng lại trong tôi lại hoàn toàn không nằm trong phần mô tả nhiệm vụ. Đó là việc cây cầu $DUSK hiện đã bị tạm dừng hơn mười ngày, và chẳng ai ở Dusk có vẻ vội vàng để mở lại. #dusk
Bối cảnh nhanh cho ai đã bỏ lỡ: vào ngày 16 tháng 8, nhóm đã phát hiện hoạt động bất thường trên một ví được dùng cho các hoạt động liên quan đến cầu, sau đó tái tạo các địa chỉ bị ảnh hưởng và đẩy một danh sách chặn người nhận qua Web Wallet sau khi một phần luồng đã đụng tới Binance. Bản thân mainnet của DuskDS không bao giờ ngừng tạo block. Đó là điểm mà tôi cứ quay lại suy nghĩ.
Tôi đã từng cho rằng một L1 tập trung vào quyền riêng tư sẽ dồn rủi ro của mình vào một nơi—lớp nền. Việc theo dõi chuỗi vẫn chạy “sạch” trong khi cây cầu bị đóng băng đã cho thấy ranh giới tin cậy ở đây không được tách theo cách như vậy. Cây cầu là một nghĩa vụ rủi ro riêng của nó, chịu trách nhiệm theo mốc thời gian riêng, độc lập với sức khỏe của sự đồng thuận.
Người dùng Binance có thể đã được bảo vệ trước tiên, chỉ nhờ việc danh sách chặn đã tồn tại trước khi các khoản rút có thể được định tuyến. Tất cả những người còn lại vẫn đang chờ “tạm thời”.
Không biết ngưỡng thực sự là gì trước khi “tạm thời” bắt đầu mang một ý nghĩa khác.
Tôi đã thực hiện một khoản chuyển nhỏ thông qua Web Wallet của Dusk vào đầu tuần này khi đang hoàn tất một tác vụ trên CreatorPad, và bị chặn giữa chừng bởi một cảnh báo trong danh sách chặn mà tôi không hề mong đợi. Không có gì quá kịch tính, chỉ là một cờ đỏ trước khi giao dịch được gửi đi. Với một chuỗi được xây dựng dựa trên mô hình quyền riêng tư cho phép tiết lộ có chọn lọc của $DUSK , #dusk , @Dusk , thì việc gặp phải điều đó lại thấy hơi lạ.
Hóa ra cảnh báo này truy vết về danh sách chặn người nhận mà đội ngũ đã tích hợp vào Web Wallet sau sự cố vào giữa tháng 8 liên quan đến một ví vận hành cầu nối bị xâm phạm. Nó sàng lọc các giao dịch đi khỏi dựa trên các địa chỉ đã bị gắn cờ trước khi bạn có thể gửi.
Tôi đã nghĩ rằng ưu tiên quyền riêng tư theo kiểu “tối ưu riêng tư” sẽ đồng nghĩa với ít điểm kiểm tra hơn, chứ không phải nhiều hơn. Việc chứng kiến nó thực sự kích hoạt trong một lần thử thật đã làm tôi thay đổi một chút suy nghĩ. Cơ chế này chỉ hoạt động nếu ai đó đang liên tục duy trì và cập nhật danh sách đó gần như theo thời gian thực, nghĩa là có một lớp “biên tập/duyệt chọn” đang âm thầm nằm dưới lớp “confidential by default” (bí mật theo mặc định).
Không nói rằng điều đó là sai, chỉ là tôi nhận ra nó. Tiết lộ có chọn lọc và sàng lọc địa chỉ không phải là cùng một thứ, nhưng giờ chúng đang cùng tồn tại trong một chiếc ví. Tôi vẫn đang tìm hiểu mức độ thoải mái của mình với điều đó, và chính xác là ai sẽ quyết định những gì được thêm vào danh sách trong tương lai.
Tuần này tôi lại kiểm tra trang trạng thái cầu Dusk và hiện vẫn đang hiển thị “tạm dừng”, giống như từ sau sự cố ngày 16 tháng 8, khi nhóm đã báo cáo có hoạt động đáng ngờ trên một ví được dùng cho các hoạt động của cầu. Chi tiết đó vẫn đọng lại trong đầu tôi khi tôi hoàn tất tác vụ CreatorPad này với @Dusk , $DUSK , #dusk : hơn chín ngày sau, các địa chỉ đã được tái sử dụng, danh sách chặn đã hoạt động, nhưng chính cây cầu vẫn chưa quay lại trực tuyến.
Phần “thông tin chính thức” thì khá gọn gàng: không phải vấn đề ở cấp độ giao thức, DuskDS vẫn tạo block bình thường, không có quỹ người dùng nào bị ảnh hưởng. Về mặt kỹ thuật thì đúng. Nhưng tôi lại hiểu “không phải lỗi giao thức” theo hướng “có thể sửa nhanh”. Không phải vậy. Hạ tầng vận hành do một nhóm quản lý—dù nằm trên một chuỗi được xây dựng quanh việc kết toán mang tính tất định và quyền riêng tư ở mức có thể kiểm toán—vẫn vận hành theo nhịp thời gian của con người, khi có thứ gì đó chạm vào một luồng tập trung.
Điều khiến tôi ấn tượng hơn cả bản thân sự cố là khoảng cách giữa mức độ tự tin của thông điệp trấn an và thời gian thực tế đang mất để khắc phục. Hai điều đó không nhất thiết mâu thuẫn, nhưng nhìn cạnh nhau thì lại đọc khác đi.
Chưa biết liệu đây chỉ là một quy trình cẩn trọng hay là vấn đề mang tính cấu trúc hơn về cách các cầu được xử lý sau sự cố. Tôi sẽ theo dõi để xem khi nào nó thực sự được mở lại.
Đọc qua bản tóm tắt CreatorPad về $DUSK , tôi bị mắc ở một dòng trong thông báo sự cố trên chính cầu nối của Dusk: nhóm đã vô hiệu hóa và tái chế một tập địa chỉ sau khi phát hiện hoạt động bất thường trên một ví do nhóm quản lý, được dùng cho các hoạt động cầu nối, rồi tạm dừng hoàn toàn các dịch vụ cầu nối trong lúc họ xử lý. #dusk
Đó là đoạn làm tôi suy nghĩ. Không phải bản thân sự cố, mà là cấu trúc phản hồi. @Dusk dành phần lớn nội dung cho quyền riêng tư phía người dùng, công bố có chọn lọc, các “đường ray” tuân thủ—tất cả những thứ được xây dựng cho người đang nắm giữ ví. Cái này không phải vậy. Đây là một khóa vận hành nội bộ bị lộ hành vi bị gắn cờ, và cách khắc phục thì rất thẳng tay: tạm dừng mọi thứ, xây dựng lại tập địa chỉ, rồi gửi một danh sách chặn người nhận để bắt mọi thứ nào đó đang cố chuyển qua web wallet.
Tôi đã nghĩ cách diễn đạt “hạ tầng được quản lý” có nghĩa là phía vận hành cũng được gia cố, có lẽ còn hơn hầu hết các L1 nhờ định hướng theo kiểu tổ chức. Hóa ra chế độ hỏng không phải là một lỗ hổng khai thác trong smart contract hay một cuộc bỏ phiếu quản trị đi lệch hướng—mà là một ví được quản lý, tức là một vấn đề vừa kém thú vị hơn, vừa phổ quát hơn rất nhiều.
Vẫn chưa chắc liệu điều đó có khiến tôi yên tâm hay ngược lại.
Điểm nổi bật nhất trong phản hồi của Dusk về cầu nối là gì?
Suốt cả tuần mình đào sâu vào cơ sở hạ tầng cầu nối của Dusk cho vòng CreatorPad này, và thứ ngăn mình lại không phải là một tính năng—mà là thông báo sự cố ngày 16 tháng 8. Đội ngũ phát hiện hoạt động đáng ngờ trên một ví mà họ kiểm soát phục vụ cho các hoạt động cầu nối, và buộc phải tắt và tái cấp (recycle) một loạt địa chỉ ngay tại chỗ. $DUSK , #dusk , @Dusk , Mình bước vào với kỳ vọng sẽ viết về đà phát triển của testnet DuskEVM. Nhưng mình rời đi với suy nghĩ về một điều hoàn toàn khác.
Đây là những gì đã khiến mình phải dừng lại: chính bản thân cây cầu không bị hỏng. Lớp zk, phần đồng thuận—không có gì trong đó bị đụng tới. Thứ “đổ” không phải là công nghệ, mà là một ví được đội ngũ vận hành quản lý: kiểu thành phần vận hành mà mọi cây cầu đều âm thầm dựa vào, và chẳng ai thực sự kiểm toán công khai. Dusk phản ứng nhanh, tạm dừng dịch vụ, và phối hợp với Binance ngay khi một phần của chuỗi vận hành được lộ ra ở đó. Ứng phó hợp lý. Nhưng nó cho thấy khoảng cách giữa “bảo mật ở cấp độ giao thức” và “những con người vận hành lớp hạ tầng”—hai thứ mà mình đã từng coi là một.
Mình đã nghĩ rủi ro của cầu nối chủ yếu nằm trong mã hợp đồng. Hóa ra bề mặt mềm hơn—mang tính vận hành—cũng “chịu lực” không kém. Vẫn chưa chắc phải kiểm toán phần đó như thế nào.
Trước khi triển khai bất cứ thứ gì, mình đã chạy một kiểm tra RPC nhanh trên testnet DuskEVM để chắc chắn rằng mình đang ở đúng mạng. Là một bước nhỏ, nhưng nó giúp gắn nhiệm vụ CreatorPad với điều gì đó thực tế thay vì chỉ dựa vào ảnh chụp tài liệu. Mình đã chuyển một lô $DUSK từ DuskDS để cấp vốn cho ví triển khai, rồi đẩy một hợp đồng Solidity cơ bản qua Hardhat. #dusk @Dusk
Thứ thực sự làm mình dừng lại không phải là việc triển khai thành công, mà là phần phân rã phí sau đó. Mình đã hiểu nhầm rằng "EVM thân thiện với quyền riêng tư" nghĩa là quyền riêng tư được tích hợp sẵn vào mọi giao dịch theo mặc định. Không phải vậy. Phí thực thi và phí khả dụng dữ liệu để đăng lô đó trở lại DuskDS đều hiển thị đầy đủ, theo kiểu tiêu chuẩn như OP-Stack. Không có lớp che chắn nào được bật trừ khi bạn chủ động định tuyến qua Hedger.
Đây là một giả định khá hợp lý để lỡ làm sai. Thông điệp của Dusk nhấn mạnh mạnh vào tính bảo mật/chống lộ thông tin, nên rất dễ kỳ vọng lớp EVM cũng được kế thừa điều đó mặc định—thay vì coi đó là thứ bạn phải tự chủ động bật riêng.
Về mặt kiến trúc thì điều đó cũng hợp lý: công cụ phục vụ settlement và quyền riêng tư được giữ tách rời khỏi phần thực thi dùng chung. Tuy vậy mình vẫn tò mò: hiện có bao nhiêu dev đang xây dựng ở đây thực sự đang tìm đến Hedger, hay chỉ đơn giản là triển khai các hợp đồng EVM tiêu chuẩn rồi chuyển sang việc tiếp theo. Đây là quan sát cá nhân của mình từ quá trình test, không phải lời khuyên tài chính—nếu bạn đang cân nhắc hệ sinh thái thì không đáng đào sâu thêm.
Bạn sẽ thử phần nào khi xây dựng trên DuskEVM trước tiên? 👇