XRPL v3.2.0 vượt ngưỡng UNL, nhưng số lượng node vẫn thấp

Phiên bản máy chủ v3.2.0 của XRP Ledger đã đạt khoảng 89% mức độ áp dụng trong số các trình xác thực UNL mặc định, vượt qua ngưỡng cần thiết để kích hoạt nếu duy trì trong hai tuần liên tiếp. Cơ sở nút rộng hơn vẫn nghiêng về v3.1.3, và một sửa đổi tập trung vào bảo mật liên quan đến phiên bản này đang có tỷ lệ bỏ phiếu thấp hơn nhiều so với tỷ lệ nâng cấp phần mềm.

Điểm nổi bật

Phần mềm máy chủ XRPL v3.2.0 đã được phát hành vào ngày 15 tháng 6 với các mục tiêu đã nêu là giảm chi phí vận hành, cải thiện tính ổn định và tăng cường sức hấp dẫn đối với các tổ chức.
Ảnh chụp của XRPSCAN cho thấy khoảng 833 nút XRPL đang hoạt động, với khoảng 43% trên v3.2.0 so với khoảng 51% vẫn đang chạy v3.1.3.
Các trình xác thực UNL mặc định đã tiến xa hơn so với cơ sở nút: 31 trong số 35 trình xác thực đang sử dụng v3.2.0, khoảng 89%.
Sửa đổi fixCleanup3_2_0 trên sổ cái, bao gồm các bản sửa lỗi bảo mật và cải tiến cho các tính năng XRPL mới hơn, vẫn đang trong quá trình bỏ phiếu và được mô tả là có tỷ lệ bỏ phiếu thấp hơn nhiều so với việc triển khai phần mềm.

V3.2.0 Vượt Qua Ngưỡng UNL Mặc Định, Chờ Cửa Sổ Hai Tuần

Phần mềm máy chủ v3.2.0 của XRPL đã được triển khai vào ngày 15 tháng 6 với một đề xuất hoạt động: rẻ hơn để vận hành, ổn định hơn và hấp dẫn hơn cho việc sử dụng của các tổ chức. Đến ngày 8 tháng 7, bản nâng cấp đã vượt qua ngưỡng quan trọng của lớp trình xác thực trên Danh sách Nút Độc Nhất mặc định.

Cơ chế kích hoạt của XRPL là nhị phân và có thời gian. “Để một phiên bản phần mềm mới hoặc sửa đổi được kích hoạt, nó cần có sự hỗ trợ liên tục từ hơn 80% các trình xác thực trong danh sách đó trong hai tuần liên tiếp.” Trên UNL mặc định của 35 trình xác thực, 31 đang chạy v3.2.0, khoảng 89%, vượt qua yêu cầu >80%. Câu hỏi mở là thời gian, vì điều kiện hai tuần chưa được xác nhận là đã được đáp ứng.

Đối với các nhà giao dịch, sự phân chia đó quan trọng vì nó định hình việc triển khai gần hoàn thành hơn ở lớp đồng thuận so với những gì mạng lưới rộng hơn ngụ ý. Sự chuẩn bị của các trình xác thực có thể cao ngay cả khi một phần lớn các nút vẫn đang ở phiên bản trước.

FixCleanup3_2_0: Sửa đổi Bảo mật trên một Lộ trình Tách biệt, Chậm hơn

Rủi ro vật chất nhiều hơn nằm ở lộ trình thứ hai. Cùng với việc phát hành phần mềm, XRPL có một sửa đổi trên sổ cái, fixCleanup3_2_0, vẫn đang trong quá trình bỏ phiếu chính thức tính đến ngày 8 tháng 7.

Sửa đổi này gộp các bản sửa lỗi bảo mật và cải tiến liên quan đến các tính năng XRPL mới hơn, bao gồm các kho tài sản đơn lẻ,khođược cấp phép,các sàn giao dịch phi tập trung, token đa mục đích (MPT), và giao thức cho vay. Nó cũng thêm các kiểm tra nội bộ nhằm ngăn chặn các tài khoản đã bị xóa để lại dữ liệu rác.

Điều quan trọng, sửa đổi này không di chuyển đồng bộ với việc nâng cấp phần mềm. Nó được mô tả là có tỷ lệ bỏ phiếu thấp hơn nhiều so với tỷ lệ chấp nhận v3.2.0, củng cố rằng “nâng cấp một trình xác thực và bỏ phiếu cho sửa đổi là hai bước khác nhau.” Ripple đã bỏ phiếu ủng hộ fixCleanup3_2_0.

Về mặt vận hành, sửa đổi này giới thiệu một ranh giới cứng cho những người chậm trễ. “Các trình xác thực không nâng cấp trước khi sửa đổi kích hoạt có nguy cơ bị cắt đứt khỏi sổ cái trong trạng thái bị chặn sửa đổi mà sổ cái gọi là trạng thái bị chặn sửa đổi.” Điều này biến việc chậm phiên bản từ một sự tách biệt thẩm mỹ thành một sự kiện kết nối tiềm năng nếu cuộc bỏ phiếu cuối cùng được thông qua.

Các tín hiệu có thể thắt chặt—hoặc kéo dài—thời gian nâng cấp

Thời gian đầu tiên là sự hỗ trợ của trình xác thực cho tính bền vững. Ngưỡng quan trọng là liệu sự hỗ trợ UNL mặc định cho v3.2.0 có giữ trên 80% trong hai tuần liên tiếp cần thiết hay không, vì đó là điều kiện kích hoạt.

Thời gian thứ hai là dọn dẹp phân phối. Sự pha trộn nút của XRPSCAN vẫn nghiêng về v3.1.3, vì vậy các nhà giao dịch sẽ theo dõi xem tỷ lệ của v3.2.0 có tăng lên, và sau đó vượt qua, tỷ lệ khoảng 51% của phiên bản cũ khi các nhà điều hành bắt kịp hay không.

Thời gian thứ ba là chính việc sửa đổi. Số phiếu bầu chính xác cho fixCleanup3_2_0 không được chỉ định, chỉ biết rằng nó thấp hơn nhiều so với việc áp dụng phần mềm, vì vậy bất kỳ tỷ lệ phần trăm nào được công bố hoặc sự tăng tốc rõ rệt trong việc bỏ phiếu sẽ trở thành chất xúc tác cụ thể tiếp theo.

Các thông tin liên lạc của nhà điều hành mà đề cập rõ ràng đến việc tránh trạng thái bị chặn sửa đổi cũng sẽ là một dấu hiệu cho thấy sự khẩn cấp của việc nâng cấp đang chuyển từ tùy chọn sang bắt buộc.

Phân tách việc áp dụng: Các validator đã được nâng cấp, nhưng cơ sở nút rộng hơn thì chưa.

XRPSCAN cho thấy khoảng 833 nút hoạt động tại thời điểm chụp ảnh, với khoảng 43% trên v3.2.0 và khoảng 51% vẫn trên v3.1.3. Đó là một sự triển khai có vẻ chậm nếu chỉ nhìn vào số lượng nút thô.

Nhưng lớp xác thực đang kể một câu chuyện khác. Trên UNL mặc định, 31 trong số 35 xác thực đã ở phiên bản v3.2.0, khoảng 89%. Trong cấu trúc thị trường của XRPL, đó là chỉ số có thể hành động hơn vì nó quyết định xem các bản nâng cấp và sửa đổi có thể thực sự chuyển sang trạng thái hoạt động hay không.

Đây là lý do tại sao các nhà giao dịch thường chú trọng đến sự sẵn sàng của UNL hơn là phân phối nút rộng rãi. Một mạng lưới có thể trông "đằng sau" về số lượng nút trong khi vẫn gần với một sự chuyển giao lớp đồng thuận, và những sự chuyển giao đó là nơi có rủi ro hoạt động và câu chuyện.biến độngcó xu hướng tập trung.

Rủi ro Kích Hoạt Hai Lộ Trình Mới Là Tín Hiệu Giao Dịch Thực Sự Ở Đây

Tôi coi đây là hai chất xúc tác riêng biệt có thể xảy ra vào những thời điểm khác nhau. v3.2.0 đã vượt qua ngưỡng UNL mặc định, vì vậy bài kiểm tra thực sự là liệu hỗ trợ đó có giữ vững trong suốt khoảng thời gian hai tuần hay không, vì đó là điều biến "đã triển khai" thành "đã kích hoạt."

Sự không chắc chắn lớn hơn là fixCleanup3_2_0. Nếu sửa đổi đó cuối cùng đạt được kích hoạt trong khi việc bỏ phiếu vẫn còn chậm, thiết lập bắt đầu trông có vẻ cấu trúc hơn là dựa vào câu chuyện, vì rủi ro bị chặn sửa đổi buộc các nhà điều hành muộn phải di chuyển.

Điều này trông giống như một chất xúc tác tâm lý hơn là một sự thay đổi cơ bản cho đến khi cuộc bỏ phiếu sửa đổi trở nên chặt chẽ và đuôi dài của mạng lưới các nút thu hẹp khoảng cách phiên bản theo cách giảm thiểu rủi ro thời gian chết bất ngờ.

Nguồn

CoinDesk