Tác giả: Blue Matt
Nguồn: https://bluematt.bitcoin.ninja/2020/01/10/modern-soft-fork-activation/
Bài viết được xuất bản vào tháng 1 năm 2020. Về mặt thời gian là ngay trước khi phương pháp kích hoạt nâng cấp Taproot được xác định.
Bài viết ban đầu được đăng trên nhóm thư bitcoin-dev, đó là một không gian thảo luận nhắm đến độc giả kỹ thuật. Nhưng được đăng lại ở đây, bởi vì nhiều người đều quan tâm đến chủ đề này. Các yêu cầu và mục tiêu của phương pháp kích hoạt soft fork đặc biệt hấp dẫn.
Gần đây, nhiều đề xuất soft fork đã đạt được tiến triển tốt trong việc triển khai và áp dụng. Tuy nhiên, vì nhiều lý do, các phương pháp kích hoạt không được thảo luận nhiều. Tôi có ý định khởi động lại cuộc thảo luận ở đây.
Trước khi bắt đầu, có vẻ như đáng để xem xét lại các mục tiêu của đề xuất soft fork và các mục tiêu của phương pháp kích hoạt của chúng. Tôi có thể bỏ sót một số điều, nhưng dưới đây là các yêu cầu cơ bản:
1) Tránh kích hoạt khi đối mặt với các phản đối lớn, hợp lý và trực tiếp. Nếu có một cách sử dụng Bitcoin được áp dụng rộng rãi, hợp lý, hiện tại có hiệu lực, và không có lý do để tin rằng ngay cả khi không có thay đổi, nó sẽ không được tiếp tục sử dụng trong tương lai, và một thay đổi sẽ làm cho cách sử dụng này không còn khả dụng hoặc đáng kể tăng độ khó sử dụng, thì thay đổi đó không nên xảy ra. Tôi rất mong điều này sẽ không gây ra sự phản đối (điểm cuối cùng đưa ra một lời cảnh báo quan trọng mà mọi người sẽ ngay lập tức chỉ ra).
2) Tránh kích hoạt trong khung thời gian không thể đạt được tỷ lệ cao các nút. Giống như tất cả các lập luận về "nút", tôi muốn chỉ ra rằng ở đây, từ "nút" có nghĩa là các nút "kinh tế", không phải hàng ngàn nút gián điệp trên Google Cloud và AWS. Nếu không có nút để thực thi, việc thay đổi quy tắc sẽ không có ý nghĩa, cho dù thay đổi quy tắc là soft fork, hard fork hay không phải là fork nào. Vì vậy, việc kích hoạt trong khung thời gian không thể đạt được việc áp dụng nút quy mô lớn sẽ không có giá trị và có thể dẫn đến các tác dụng phụ không mong muốn.
3) Không (không cần thiết) làm cho các thợ đào không nâng cấp không thể cung cấp tỷ lệ băm. Bởi vì một phần an ninh của Bitcoin đến từ các thợ đào, nếu hệ quả của một thay đổi quy tắc là giảm tỷ lệ băm của mạng, thì đó là việc làm suy yếu một tham số an ninh quan trọng một cách không cần thiết. Đây là lý do tại sao trong các soft fork gần đây nhất, đều yêu cầu 95% tỷ lệ băm cho biết họ đã nâng cấp và có khả năng thực thi các quy tắc mới. Hơn nữa, đây cũng là lý do tại sao các đề xuất soft fork gần đây không bao gồm các thay đổi làm cho chức năng khai thác của các phiên bản Bitcoin Core tiêu chuẩn bị vô hiệu (tức là, yêu cầu thay đổi dựa trên hành vi tiêu chuẩn của Bitcoin Core).
4) Sử dụng tỷ lệ băm để thực thi để loại bỏ rủi ro trong quá trình nâng cấp bất cứ khi nào có thể. Như là kết quả tất yếu của các điểm trên, một trong những lý do chính chúng ta sử dụng soft fork là việc thực thi quy tắc dựa trên tỷ lệ băm là một cách tinh tế để ngăn ngừa sự phân chia mạng trong quá trình nâng cấp nút. Mặc dù không khôn ngoan khi đầu tư nhiều giá trị vào hệ thống được bảo vệ bởi các quy tắc mới trước khi một tỷ lệ đáng kể các "nút kinh tế" bắt đầu thực thi các quy tắc mới, nhưng tỷ lệ băm vẫn cho phép chúng ta khéo léo lấp đầy khoảng trống thời gian giữa thời điểm kích hoạt và việc áp dụng rộng rãi. Bằng cách buộc đa số các thợ đào thực thi các quy tắc mới, các nỗ lực vi phạm quy tắc mới sẽ không dẫn đến sự phân chia mạng bị hạn chế và không gây trở ngại cho người dùng hệ thống hiện tại. Nếu chúng ta không sẵn sàng tận dụng điều này, chúng ta nên chuyển sang hard fork, và các bước thời gian sẽ chắc chắn bị chậm lại.
5) Tuân theo ý chí của cộng đồng, không quan tâm đến các phản đối cá nhân, không hợp lý, nhưng không nên bác bỏ các phản đối hợp lý. Gần đây cũng đã xuất hiện một hình thức "phản đối" soft fork: "Đề xuất này không tốt vì nó không sửa một vấn đề khác mà tôi cho là cần phải sửa ngay lập tức". Tôi không nghĩ rằng ai đó sẽ coi đây là một phản đối hợp lý, và chúng ta nên đứng cùng nhau, như một cộng đồng (không phải là các nhà phát triển hoặc một nhóm cụ thể nào), bỏ qua những ý kiến như vậy và tiến lên phía trước. Việc "gói" các tính năng không liên quan sẽ không mang lại quyết định kỹ thuật khôn ngoan, mà chỉ mang lại sự chậm trễ và thỏa hiệp về mặt chính trị.
Tôi tin rằng BIP 9 (cộng với một đề xuất soft fork được tạo ra một cách khéo léo) có thể kiểm tra rất hiệu quả các điểm 2-4 trong danh sách trên; với sự tham gia của cộng đồng và xem xét cẩn thận, nó có thể hiệu quả trong việc đáp ứng điểm 1. Đối với điểm 5, tôi chắc chắn rằng mọi người đã nhận thấy, đây là nơi mọi thứ bắt đầu trở nên khó khăn.
(Phần còn lại của bản dịch sẽ tiếp tục theo cùng phong cách)1) Một quy trình triển khai BIP 9 tiêu chuẩn, với cửa sổ thời gian một năm để kích hoạt, yêu cầu 95% thợ đào sẵn sàng; 2) Trong trường hợp không thể kích hoạt trong một năm, thiết lập một giai đoạn im lặng kéo dài 6 tháng, cộng đồng có thể phân tích và thảo luận về lý do không kích hoạt; 3) Trong các trường hợp hợp lý, cung cấp một lệnh dòng lệnh/tham số tệp cấu hình đơn giản trong phiên bản phát hành phần mềm đầu tiên, cho phép người dùng chọn quy trình triển khai BIP 8 với cửa sổ thời gian 24 tháng để thúc đẩy kích hoạt tín hiệu (đồng thời, các phiên bản Bitcoin Core mới sẽ tự động kích hoạt nhãn này).
Điều này cung cấp một cửa sổ thời gian rất dài cho phương pháp kích hoạt tiêu chuẩn hơn; mặc dù, để đảm bảo vẫn đáp ứng mục tiêu thứ 5, cần phải đáng kể kéo dài thời gian để đảm bảo đáp ứng mục tiêu thứ 3. Phát triển Bitcoin không phải là một cuộc đua. Nếu cần thiết, việc chờ đợi 42 tháng có thể đảm bảo chúng ta không thiết lập một tiền lệ tiêu cực sẽ khiến chúng ta hối tiếc về sau.
(Kết thúc)
