Nâng cấp bản thử nghiệm Namada Testnet v0.13.0

Nâng cấp giao thức được kích hoạt của Namada theo chiều cao đã thất bại trong việc kích hoạt trên bản testnet tại block height#37370 (ngày 18 tháng 1 năm 2023 giữa 19:00-21:00 UTC). Bài viết này là một dự đoán về những điều đã xảy ra và các bước chúng tôi thực hiện kế hoạch để tránh loại vấn đề này trong tương lai.

Các giao dịch bị từ chối bởi các Validity Predicates.

Bản public testnet Namada mới nhất được tạo ra vào ngày 12 tháng 1 năm 2023 lúc 17:00 UTC sau quá trình khởi động phân tán, với phiên bản phát hành Namada 0.13.0.

Sau khi khởi động, network đã chạy ổn định, nhưng nhiều thành viên cộng đồng báo cáo về các vấn đề liên quan đến giao dịch. Coreteam đã điều tra và phát hiện ra vấn đề nằm trong 2 trường được bao gồm trong các tệp khởi động được gọi là  whitelist_vp  và whitelist_tx.. Các giao dịch đã được chấp nhận và thêm vào mempool, nhưng một khi được thực thi và chèn vào các khối, validity predicates đã từ chối chúng.

Các trường này chứa các băm giao dịch và validity predicate của các tệp WASM đã được cho phép. Vấn đề là hai mảng này chứa các băm dưới dạng chữ thường. Trước khi bao gồm các giao dịch, Namada kiểm tra xem các giao dịch được thực thi và validity predicate  có băm của chúng trong cácwhitelists . Cụ thể, &vp_hash.to_string() và &tx_hash.to_string()trả về băm chữ hoa, do đó các kiểm tra đã thất bại. Việc sửa lỗi bao gồm bao gồm các băm dưới dạng chữ hoa trong tệp khởi động. Mã đã được fixed bằng cách viết hai mảng vào bộ nhớ tất cả đều dưới dạng chữ thường và làm cho các kiểm tra không phân biệt chữ hoa và chữ thường.

Để triển khai sửa lỗi này, mạng yêu cầu nâng cấp lên phiên bản giao thức đã vá v.0.13.1. Để đảm bảo đủ thời gian cho việc phối hợp nâng cấp phân tán mà không dừng mạng, việc nâng cấp được lập trình để diễn ra trong tương lai tại khối chiều cao 37370.

Vấn đề trong quá trình phát hành giao thức

Ngày 17 tháng 1, cộng đồng Namada được thông báo về việc phát hành và hướng dẫn nâng cấp mạng với bản vá. Vấn đề là đã có hai phiên bản phát hành được đăng với tên là v0.13.1 and v0.13.1-hardfork. Nhiều lần thông báo đã được phát hành để yêu cầu nâng cấp các nút của họ lên v0.13.1-hardfork. Thật không may, một số nhà xác nhận đã nâng cấp lên v0.13.1, trong khi những người khác nâng cấp lên v0.13.1-hardfork, dẫn đến hai trạng thái gốc khác nhau tại độ cao khối 37370. Mạng đã phân nhánh thành hai nhánh, mỗi nhánh không có đủ sức mạnh bỏ phiếu (2/3) để tiếp tục sản xuất khối.

Trong quá trình điều tra, nhóm cũng phát hiện ra rằng cả hai phiên bản giao thức đều chứa một lỗi khác có thể ngăn các nút từ việc đồng bộ hóa từ đầu.

Giao thức bảng đã được chỉnh sửa và con đường cần triển khai

Một phiên bản giao thức mới chứa mã đúng đã được tạo ra: v0.13.2. Sau khi đánh giá cẩn thận, nhóm tìm thấy hai lựa chọn để triển khai nó: nâng cấp hoặc khởi động lại mạng.

Tùy chọn 1)

Khôi phục mạng bằng cách nâng cấp khác Lựa chọn này yêu cầu phối hợp với các validator trong cộng đồng đang sử dụng phiên bản v0.13.1 để nâng cấp lên v0.13.2 (nhưng không phải những người đang sử dụng v0.13.1-hardfork). Khi có thể, việc khôi phục mạng luôn là lựa chọn ưu tiên, nhưng trong trường hợp này, tùy chọn này mang lại rất nhiều độ phức tạp và do đó có nguy cơ thất bại, bởi vì nó liên quan đến: tạo ra một phiên bản phát hành có thể đồng bộ lại từ 0 (2,5-3 giờ) (chỉ liên quan đến các nút trên v0.13.1) và sau đó kích hoạt hardfork; để kiểm tra phiên bản phát hành, mô phỏng hardfork trên devnet; giao tiếp và chờ đợi tất cả các nhà xác nhận bị ảnh hưởng nâng cấp lên phiên bản chính xác.

Tùy chọn 2)

Option này đòi hỏi Khởi động lại mạng, yêu cầu phát hành v0.13.2, kiểm tra phiên bản trên devnet và khởi động lại mạng với cùng bộ validators genesis như vào ngày 12 tháng 1 năm 2023 với phiên bản giao thức chính xác.

Going forward

Với độ phức tạp và rủi ro liên quan đến phối hợp trong một mạng phi tập trung với tùy chọn 1, nhóm đã đề xuất tiếp tục với việc khởi động lại mạng. Để tránh các vấn đề tương tự trong tương lai, nhóm đã đồng ý với các cải tiến quy trình sau đây:

  • Các cấu hình Devnets (mạng testnet trung tâm,nội bộ cho Q / A) sẽ gần như giống như các public testnets, bao gồm cấu hình genesis. Điều này đã giúp phát hiện vấn đề với kiểm tra hash whitelist .
  • Tập trung vào một phiên bản duy nhất, giảm đáng kể rủi ro của các validator nâng cấp lên các phiên bản khác nhau.

Tham gia (Join)máy chủ Discord của Namada để đóng góp ý kiến và câu hỏi.

Bài viết mới nhất

Sự Bùng Nổ Của Thời Đại Multi-Chain

Thời đại Multi-Chain đang đến với một loạt ứng dụng mới hứa hẹn tận dụng sức mạnh của web3 mà không bị giới hạn...

Agoric: Sử dụng Orchestration với 5 thiết kế ứng dụng đa chuỗi.

Đối với Orchestration, Five Multi-Chain App Designs - 5 Thiết Kế Ứng Dụng Đa Chuỗi, là một khái niệm quan trọng. Agoric sắp ra...

Tầm nhìn về Liquid Staking và Restaking của Persistence One.

Tầm nhìn của chúng tôi về Liquid Staking và Restaking là xem xét sự phát triển và ứng dụng của công nghệ blockchain trong...

Chuyển đổi an ninh của Bitcoin sang Persistence One.

Persistence One hợp tác với Babylon để mở khóa tiềm năng của 21 triệu BTC nhằm bảo vệ hệ sinh thái Liquid Staking và...