Trang sửa đổi đã biết của XRPL liệt kê fixCleanup3_1__3 để kích hoạt vào ngày 27 tháng 5, và theo thiết kế, sự kiện này là một bản nâng cấp bảo trì.
Bản cập nhật rippled phiên bản 3.1.3 bao gồm các bản sửa lỗi cho NFT, Domain được phép, Vault và Giao thức Cho vay, và blog XRPL đặt phiếu bầu mặc định là Có vì tầm quan trọng của những bản sửa lỗi đó.
Quá trình sửa đổi yêu cầu hơn 80% sự ủng hộ từ các validator đáng tin cậy duy trì trong hai tuần trước khi các quy tắc mới trở thành chính thức.
Điều khiến tập phim đáng xem xét ngoài thời hạn là điều mà đồng sáng lập XRPL David Schwartz nói về những gì thực sự cần có trong một fork thật sự, bởi câu trả lời của ông tiết lộ cách thức xác thực giao thức hoạt động trên bất kỳ blockchain nào.
Điểm mấu chốt của Schwartz là số lượng nút thô là một proxy kém cho sức mạnh đồng thuận. Một hệ thống nơi các nút bỏ phiếu tỷ lệ với số lượng của chúng tạo ra bề mặt tấn công mà bất cứ ai cũng có thể khởi chạy hàng nghìn máy móc với chi phí thấp.
Trong mô hình XRPL, mỗi nhà khai thác máy chủ duy trì một bộ validator được chọn lọc mà máy chủ tin tưởng không thông đồng, gọi là Danh sách Nút Độc nhất (UNL), và UNL quyết định phiếu bầu xác thực nào được máy chủ tính toán trong quá trình đồng thuận.
Quá trình sửa đổi XRPL đòi hỏi sự ủng hộ từ hơn 80% các validator đáng tin cậy duy trì trong hai tuần trước khi các quy tắc mới trở thành chính thức, ngăn chặn các máy chủ chưa cập nhật.
Một máy chủ nhận các thông điệp xác thực từ nhiều nút trên mạng lưới, và các validator trong UNL của nó quyết định thông điệp nào sẽ định hình quan điểm của máy chủ về sổ cái.
Schwartz giải thích rằng tính hợp pháp của đồng thuận trên XRPL chảy qua danh sách niềm tin và sự phối hợp giữa các validator, tạo ra một hệ thống mà sự đồng bộ hóa UNL và việc áp dụng kinh tế quyết định sổ cái nào tồn tại sau khi phân tách.
Tại sao một fork thật sự cần một chiến dịch phối hợp đầy đủ
Đối với cuộc bỏ phiếu XRPL vào ngày 27 tháng 5, các máy chủ bị chặn sửa đổi sẽ mất khả năng xác định tính hợp lệ của sổ cái, gửi hoặc xử lý giao dịch, tham gia đồng thuận, hoặc bỏ phiếu về các sửa đổi trong tương lai.
Điều đó làm cho thời hạn trở nên quan trọng về mặt vận hành đối với bất kỳ sàn giao dịch, ví, trình khám phá hay nhà điều hành cơ sở hạ tầng nào vẫn đang chạy phần mềm trước phiên bản 3.1.3, vì những máy chủ đó sẽ trở thành không tham gia vào sổ cái chuẩn cho đến khi nhà điều hành cập nhật.
Cơ sở hạ tầng bị chặn sửa đổi sẽ mất quyền truy cập vào chuỗi đã nâng cấp và thiếu cơ sở hạ tầng phối hợp để làm điểm tựa cho một đối thủ hoạt động.
Để tạo ra một fork đáng tin cậy, nhóm bất đồng sẽ cần các validator sẵn sàng tiếp tục tạo ra sổ cái theo quy tắc cũ, và nếu không có validator, sẽ không có dòng sổ cái nào để theo dõi.
Sau đó, họ sẽ cần một Danh sách Nút Độc nhất cạnh tranh mà các máy chủ có thể cấu hình hoặc phần mềm mặc định sử dụng, bởi vì nếu không có danh sách validator đáng tin cậy, các nút không có cơ chế phối hợp xung quanh quy tắc cũ.
Ngoài ra, họ sẽ cần một phân phối mã giữ nguyên quy tắc cũ và đi kèm với cấu hình mặc định trỏ tới UNL đối thủ, đồng thời cần hỗ trợ cơ sở hạ tầng từ ví, sàn giao dịch, trình khám phá và ứng dụng đủ để làm cho sổ cái quy tắc cũ dễ tiếp cận và giao dịch được.
Một fork XRPL đáng tin cậy đòi hỏi năm lớp vượt xa các nút chưa cập nhật: validator quy tắc cũ, UNL đối thủ, mã quy tắc cũ, hỗ trợ cơ sở hạ tầng và sự công nhận thị trường.
Tài liệu XRPL trích dẫn nghiên cứu cho thấy các UNL cạnh tranh có thể cần 90% trùng khớp trong trường hợp xấu nhất để ngăn chặn fork, nghĩa là bất kỳ UNL đối thủ nào cũng phải chia sẻ gần như toàn bộ danh sách validator đáng tin cậy với UNL chuẩn để duy trì sự đồng bộ nội bộ.
Một fork hình thành xung quanh một bộ validator hoàn toàn khác biệt có nguy cơ tạo ra một sổ cái không thể duy trì đồng thuận riêng, chứ đừng nói đến việc thu hút sự áp dụng trên thị trường.
Thực chất quá trình sửa đổi theo dõi sự ủng hộ của validator, và ngưỡng 80% trong hai tuần đảm bảo rằng các thực thể mà mạng lưới tin tưởng đã đạt được thỏa thuận bền vững trước khi các quy tắc mới trở thành chính thức.
Một phần lớn các nút không phải validator chưa cập nhật có thể phản ánh sự chậm trễ cơ sở hạ tầng mà không hàm ý gì về hướng đi của sổ cái chuẩn.
Khoảng cách giữa sự chậm trễ cơ sở hạ tầng và một chuỗi đối thủ
Trong kịch bản tiêu cực, các sàn giao dịch, ví hoặc nhà điều hành cơ sở hạ tầng chậm trễ so với hoạt động ngày 27 tháng 5 sẽ bị chặn sửa đổi và ngừng hoạt động như những người tham gia sổ cái.
Người dùng kết nối qua các nhà cung cấp đó sẽ gặp gián đoạn dịch vụ, chẳng hạn như giao dịch không thể gửi, trình khám phá không thể xác nhận tính hợp lệ của sổ cái, và ứng dụng không thể xử lý thanh toán.
Chi phí vận hành đó rơi vào các nhà điều hành đã ưu tiên thấp việc nâng cấp, và điều này rất đáng theo dõi, đặc biệt đối với bất kỳ sàn giao dịch lớn nào hoặc đơn vị lưu ký vẫn đang chạy các nút trước phiên bản 3.1.3 tại thời điểm kích hoạt.
Sự chậm trễ cơ sở hạ tầng kéo dài ở đủ nhà cung cấp sẽ tạo ra ma sát thực sự đối với người dùng ngay cả khi sổ cái chuẩn tiếp tục hoạt động dưới các quy tắc mới.
Trong kịch bản tích cực, fixCleanup3_1_3 sẽ kích hoạt đúng lịch trình với đa số validator còn nguyên vẹn, các nhà điều hành cơ sở hạ tầng cập nhật mà không xảy ra sự cố lớn, và tập phim trở thành một hoạt động sửa đổi thường xuyên.
Các bản sửa lỗi cho NFT, Domain được phép, Vault và Giao thức Cho vay có hiệu lực, và mạng lưới tiến lên. Cuộc tranh luận về quản trị mà bản nâng cấp mang lại sẽ tồn tại dù kết quả nào, bởi vì lời giải thích của Schwartz về những gì một phân tách thật sự cần áp dụng cho bất kỳ sửa đổi trong tương lai.
Duy trì quy tắc cũ đòi hỏi một nhóm bất đồng chạy phần mềm cũ, tuyển dụng validator xung quanh một UNL cạnh tranh, và thuyết phục ví, sàn giao dịch và các nhà thị trường công nhận sổ cái của họ là Sổ cái XRP chuẩn, chống lại cấu hình mặc định hướng tất cả mọi người tới chuỗi đã nâng cấp.
Mọi blockchain đều có một lớp quản trị
Schwartz đưa ra so sánh với Stellar, bản nâng cấp Protocol 24 của Stellar chính là một bản sửa lỗi ổn định cho lỗi lưu trữ trạng thái trong Stellar Core, vốn là một sự kiện bảo trì đòi hỏi cùng kiểu áp dụng validator phối hợp.
Lớp tính hợp pháp tương đương của Bitcoin chạy qua các thợ đào, nút kinh tế, triển khai khách hàng và các niêm yết sàn giao dịch. Ethereum thì chạy qua các validator, cơ sở hạ tầng staking, đa dạng khách hàng, nhà phát triển cốt lõi và việc áp dụng ở lớp ứng dụng.
Điều XRPL làm rõ thông qua UNL, các mạng lưới khác tích hợp vào phân bổ sức mạnh khai thác, kinh tế staking hoặc sự đồng thuận xã hội mà các nhà phát triển phần mềm khách hàng tin tưởng.
Các cơ chế khác nhau giữa Bitcoin, Ethereum và XRPL, trong khi sự phụ thuộc vào các quyết định phối hợp của con người để biến đổi quy tắc thành chính thức diễn ra ở cả ba mạng lưới.
Trên XRPL, Bitcoin, Ethereum và Stellar, các thay đổi quy tắc trở thành chính thức thông qua các quyết định phối hợp của validator, thợ đào, nhà phát triển và thị trường, thay vì chỉ dựa vào số lượng nút thô.
Kích hoạt ngày 27 tháng 5 minh họa cách lớp quản trị của XRPL chuyển đổi sự đồng thuận của validator thành tính bền vững của sổ cái, với cấu hình UNL quyết định những thỏa thuận nào được tính.
Một nhà điều hành không đồng ý với fixCleanup3_1_3 có quyền tự do kỹ thuật để chạy phần mềm cũ và cấu hình một UNL đối thủ.
Liệu bất kỳ sàn giao dịch nào liệt kê token kết quả, ví nào hỗ trợ nó, hay nhà tạo lập thị trường nào cung cấp thanh khoản là câu hỏi mà giao thức không thể trả lời giúp họ.
Sự tách rời phối hợp này là lý do tại sao các bản nâng cấp giao thức trên các mạng lưới được áp dụng rộng rãi hiếm khi tạo ra các fork bền vững: kinh tế của việc theo dõi chuỗi chuẩn gần như luôn vượt trội so với kinh tế xây dựng một chuỗi song song từ đầu, và chuỗi chuẩn chính là chuỗi mà thị trường quyết định là thật.
Bài viết Bản nâng cấp XRPL ngày 27 tháng 5 cho thấy cách validator và thị trường quyết định một phân tách blockchain xuất hiện lần đầu trên CryptoSlate.