Trang chủ Sự kiện Không, giao thức protocol không bị khóa

Không, giao thức protocol không bị khóa

bởi Tuấn Hưng

Gần đây, Brad Jasper hay còn gọi là @synfonaut đã bắt đầu một danh sách tất cả các thay đổi đang chờ xử lý cần thiết để thực sự hoàn nguyên về giao thức Bitcoin ban đầu v0.1.

Về mặt kỹ thuật, giao thức Bitcoin SV không bị khóa, mặc dù khẳng định đã được ad-nauseam lặp lại. Trong bài viết này, tôi sẽ xem xét những thay đổi đang chờ xử lý, một số chi tiết và lịch sử đằng sau chúng, nhưng tại sao thực tế này không phải là điều mà các nhà phát triển nên lo lắng khi xây dựng trên BSV.

Thuật toán điều chỉnh độ khó

Đây là sự thay đổi triệt để nhất so với giao thức ban đầu của Satoshi và là giao thức có ảnh hưởng sâu sắc đến các biện pháp khuyến khích thợ đào kể từ khi được nhà phát triển BCH Amaury Sechet sửa đổi vào tháng 8 năm 2017. Tôi đã viết về điều này trước đây. Trên kho lưu trữ của Brad, Dean Little cho biết thêm lý do tại sao nó nên được hoàn nguyên (đặc biệt là bây giờ với giới hạn ban đầu được nâng lên):

Dean Little adds more reasons
Source: GitHub

SIGHASH_FORKID

Sự sai lệch có tác động lớn thứ hai là việc bổ sung FORKID trong thuật toán sighash, bổ sung tính năng bảo vệ phát lại, đảm bảo rằng các giao dịch chi cho BCH sẽ không nhất thiết phải chi cho BTC. Đây là một người đàn ông Pháp đặc biệt khác có thể đã gây ra những hậu quả không lường trước được. Thêm bảo vệ chơi lại có thể được hiểu là sự chấp nhận thất bại của BCH vào thời điểm đó. Động thái này cho phép các giao dịch được phát có chọn lọc trên một trong hai chuỗi, đảm bảo sự phân tách vĩnh viễn vẫn tồn tại.

Ngoài ra, nếu bất kỳ giao dịch ngoại tuyến nào được tạo bằng tính năng nLockTime trước tháng 8 năm 2017, thì các giao dịch đó hiện không thể chi tiêu trên chuỗi BCH và BSV. Hàm ý khá thú vị khi một số người Úc say mê với nLockTime, giao dịch ngoại tuyến và ủy thác.

Thay đổi opcode

Cuối cùng một số mã opcodes vẫn bị vô hiệu hóa. Bí ẩn nhất trong số đó là OP_VER, mục đích của nó vẫn chưa được biết đến nhiều. Trong trang trình bày bên dưới Craig Wright trình bày rằng nó có thể được tận dụng để triển khai các quy tắc ‘đồng thuận thứ cấp’ (mã tùy chỉnh?), Điều này thật thú vị khi xem xét rằng một trong những chủ đề tranh luận lớn là về mã opcode (OP_CHECKDATASIG) trong quá trình phân tách BCH / BSV hoàn toàn không cần thiết!

SPV connectivity to the core
Nguồn: @cryptoAcorns ảnh từ CG London 2020

Cùng với OP_VER, OP_VERIF và OP_VERNOTIF cũng sẽ được kích hoạt lại trong bản cập nhật Chronicle. Hai mã opc khác, OP_2MUL và OP_2DIV được cho là sẽ được bật lại nhưng không cần thiết vì chức năng tương tự có thể được sao chép bằng cách sử dụng OP_MUL hoặc OP_DIV (nhân và chia) của bất kỳ giá trị nào cho hai (OP_2).

Tóm lại, những thay đổi ở trên cuối cùng sẽ cần phải được thực hiện nhưng đối với mục đích của câu chuyện ‘đặt trong đá’, giao thức chỉ có vậy. Định nghĩa của tôi phản ánh với tuyên bố của Elas Digital bên dưới:

Mỗi thay đổi mà tôi đã xem xét có thể ảnh hưởng đến các bên khác nhau trong các tình huống khác nhau nhưng sẽ không làm gián đoạn bất kỳ doanh nghiệp nào đang được xây dựng ngày hôm nay trong tương lai. Nếu bất cứ điều gì, những phục hồi này chỉ có thể tăng khả năng những gì có thể được xây dựng trên Bitcoin, chứ không phải lấy đi. Bản cập nhật Chronicle trong tương lai vẫn chưa có ngày, nhưng được dự đoán sẽ mở ra nhiều tiềm năng hơn nữa từ Bitcoin.

0 bình luận

Có thể bạn cũng quan tâm

Để lại bình luận