Triết lý phát triển Bitcoin: Nâng cấp

Bài viết này được dịch máy
Xem bản gốc

Tác giả: Kalle Rosenbaum & Linnéa Rosenbaum

Nguồn: https://bitcoindevphilosophy.com/#upgrading

Xem bài viết trước tại đây.

biểu ngữ nâng cấp

Nâng cấp Bitcoin một cách an toàn là vô cùng khó khăn. Những thay đổi như vậy (ngay cả khi nội dung là dứt khoát) có thể mất nhiều năm để triển khai. Trong chương này, chúng ta sẽ tìm hiểu về các thuật ngữ phổ biến liên quan đến nâng cấp Bitcoin , xem xét một số trường hợp nâng cấp lịch sử và những bài học chúng ta có thể rút ra từ đó. Cuối cùng, chúng ta sẽ thảo luận về " Chuỗi blockchain " và các chi phí cũng như rủi ro liên quan.

Để hiểu rõ hơn chương này, bạn nên bắt đầu với bài viết của David Harding về " Sự hài hòa và bất hòa ":

Các chuyên gia Bitcoin thường sử dụng từ "đồng thuận", một từ khá trừu tượng và khó giải thích bằng vài từ. Tuy nhiên, từ nguyên của "đồng thuận" là từ tiếng Latinh "concentus", có nghĩa là "hát hòa âm" [1]. Do đó, chúng ta có thể thảo luận về "sự hòa âm của Bitcoin" thay vì "sự đồng thuận của Bitcoin".

Sự hài hòa là yếu tố giúp Bitcoin hoạt động. Hàng ngàn nút đầy đủ hoạt động độc lập: xác minh tính hợp lệ của các giao dịch mà chúng nhận được, từ đó tạo ra sự đồng thuận hài hòa về trạng thái của sổ Bitcoin, mà không có bất kỳ người điều hành nút tin tưởng người điều hành khác. Nó giống như một dàn hợp xướng mà mọi thành viên cùng hát một bài hát vào cùng một thời điểm, tạo ra một giai điệu hay hơn bất kỳ thành viên nào hát riêng lẻ.

Kết quả hài hòa của Bitcoin là một hệ thống an trong đó , không chỉ chống lại kẻ trộm (miễn là bạn giữ an toàn private key của mình), mà còn chống lại lạm phát vô tận, tịch thu quy mô lớn và có chủ đích, và thoát khỏi sự rườm rà quan liêu của hệ thống tài chính truyền thống.

— David Harding, Sự hài hòa và bất hòa

Chương này thảo luận về cách nâng cấp Bitcoin mà không gây ra bất hòa. Duy trì sự hài hòa, hay sự đồng thuận, thực sự là một trong những thách thức lớn nhất trong quá trình phát triển Bitcoin. Cơ chế nâng cấp có nhiều chi tiết, và cách tốt nhất để hiểu nó là nghiên cứu các ví dụ thực tế về nâng cấp trong quá khứ. Vì lý do này, phần này dành khá nhiều không gian cho các trường hợp lịch sử; để làm được điều đó, chúng ta sẽ bắt đầu bằng cách tìm hiểu một số thuật ngữ hữu ích.

5.1 Từ

Theo Wikipedia, "khả năng tương thích ngược " đề cập đến khả năng của phần mềm cũ xử lý dữ liệu do phần mềm mới tạo ra và bỏ qua những phần mà phần mềm mới không thể hiểu được.

Nếu một sản phẩm được biên dịch bằng phiên bản cũ hơn có thể xử lý "một cách trơn tru" các dữ liệu đầu vào được thiết kế cho các phiên bản sau của cùng một tiêu chuẩn, bỏ qua các phần mà nó không hiểu, thì chúng ta nói rằng tiêu chuẩn đó hỗ trợ "khả năng tương thích ngược".

— Khả năng tương thích ngược, Wikipedia

Ngược lại, " khả năng tương thích ngược " có nghĩa là dữ liệu từ phần mềm cũ cũng có sẵn trên phần mềm mới hơn. Nếu một thay đổi vừa tương thích tiến vừa tương thích ngược, chúng ta nói rằng thay đổi đó "hoàn toàn tương thích".

Nếu một thay đổi đối với các quy tắc đồng thuận của Bitcoin hoàn toàn tương thích, chúng ta gọi đó là " soft fork ". Đây là cách phổ biến nhất nâng cấp Bitcoin, và chúng ta sẽ thảo luận về nhiều lý do trong đó điều này trong các phần sau của chương này. Nếu một thay đổi đối với các quy tắc đồng thuận của Bitcoin tương thích ngược nhưng không tương thích tiến, chúng ta gọi đó là " hard fork ".

Để có cái nhìn tổng quan về mặt kỹ thuật về soft fork hard fork, vui lòng đọc Chương 11 của cuốn *Grokking Bitcoin* . Chương này giải thích các thuật ngữ và đi sâu vào cơ chế nâng cấp . Tôi khuyên độc giả nên đọc lướt chương này trước khi tiếp tục, mặc dù điều đó không bắt buộc.

5.2 Nâng cấp lịch sử

Bitcoin ngày nay (giao thức) khác biệt so với thời điểm khối đầu tiên được tạo ra. Đã có lần nâng cấp trong những năm qua. Năm 2017, Eric Lombrozo, tại hội nghị Breaking Bitcoin , đã giải thích các cơ chế nâng cấp khác nhau của Bitcoin , chỉ ra rằng nâng cấp này cũng đã trải qua nhiều thay đổi. Ông thậm chí còn giải thích cách Satoshi Nakamoto nâng cấp Bitcoin thông qua hard fork .

Trên thực tế, Satoshi Nakamoto đã từng sử dụng hard fork để nâng cấp Bitcoin một lần—và chúng tôi sẽ không bao giờ làm điều đó nữa vì đó là một cách tiếp cận tồi tệ. Hãy xem mô tả commit git [ 757f076 ], trong đó nói rằng commit này nhằm mục đích khôi phục makefile.unix wx-config về phiên bản 0.3.6. Chỉ vậy thôi. Ông ấy hoàn toàn không đề cập đến việc đây là một thay đổi mang tính phá hủy. Về cơ bản, ông ấy đã che giấu điều đó. Ông ấy cũng đăng bài trên diễn đàn bitcoin talk , kêu gọi tất cả người dùng nâng cấp lên phiên bản 0.3.6 càng sớm càng tốt; nếu bạn không thể nâng cấp ngay lập tức, tốt nhất là nên tắt nút Bitcoin của bạn trước. Dựa trên thông tin trên, tôi không biết tại sao ông ấy lại làm như vậy—ông ấy đồng thời quyết định thêm một số tối ưu hóa, sửa lỗi và các cải tiến khác vào cùng một mã.

— Eric Lombrozo, "Thay đổi các quy tắc đồng thuận mà không phá vỡ Bitcoin ", Hội nghị Phá vỡ Bitcoin (2017)

Lombrozo cũng chỉ ra rằng, dù cố ý hay vô ý, hard fork lần đã tạo ra cơ hội cho soft fork trong tương lai vì nó đã giới thiệu các mã lệnh script OP_NOP1 ~ OP_NOP10 . Chúng ta sẽ tìm hiểu thêm về sự thay đổi mã lần trong Mục 9.2.1 . Cho đến nay, các mã lệnh này đã được sử dụng lần soft fork: BIP65 (OP_CHECKLOCKTIMEVERIFY) và BIP113 (OP_SEQUENCEVERIFY). (Ghi chú của người dịch: Hai mã lệnh này được sử dụng để xác minh khóa thời gian tuyệt đối và tương đối trong các script, tương ứng.)

Lombrozo cũng tóm tắt ngắn gọn những thay đổi nâng cấp qua các năm (tính đến năm 2017). Kể từ đó, chỉ có một nâng cấp, "Taproot," được triển khai (xem phần 5.2.3 để biết chi tiết). Quá trình kích hoạt dài dòng và có phần phức tạp này đã giúp chúng ta hiểu rõ hơn về cơ chế nâng cấp Bitcoin .

5.2.1 Nâng cấp "Chứng thực cách ly"

Mặc dù tất cả nâng cấp trước nâng cấp Segwit đều có thể được mô tả là khá suôn sẻ, nhưng bản nâng cấp này lại khác. Khi mã kích hoạt Segwit được phát hành (tháng 10 năm 2016), dường như phần lớn người dùng Bitcoin đều ủng hộ nó, nhưng vì một lý do nào đó, thợ đào không bày tỏ sự ủng hộ đối với lần nâng cấp, điều này khiến quá trình kích hoạt bị đình trệ và dường như không có giải pháp nào.

Trong bài viết " Con đường dài đến Segregated Witness " được đăng trên trang web Bitcoin Magazine, Aaron van Wirdum đã mô tả hành trình đầy biến động này. Trước tiên, ông giải thích nâng cấp Segregated Witness là gì và làm thế nào nó lại vướng vào cuộc tranh luận về việc thay đổi giới hạn kích thước khối Bitcoin. Sau đó, van Wirdum phác thảo các sự kiện then chốt cuối cùng dẫn đến việc kích hoạt nó. Trong đó yếu tố quan trọng là cơ chế nâng cấp được gọi là " Soft Fork do người dùng kích hoạt (UASF)", do người dùng "Schaolinfry" đề xuất.

Shaolinfry đề xuất một giải pháp thay thế: Soft Fork do người dùng kích hoạt (User-Activated Soft Fork - UASF). Thay vì để tỷ lệ băm băm (hash power) quyết định, họ thiết kế một "ngày tín hiệu kích hoạt" mà người dùng sẽ thực thi từ một thời điểm được xác định trước trong tương lai. Nếu UASF được đa số các tác nhân kinh tế thực thi, nó sẽ thuyết phục hầu hết thợ đào) làm theo (hoặc kích hoạt) soft fork .

— Aaron van Wirdum, “Con đường dài dẫn đến việc chứng kiến ​​biệt lập”, Tạp chí Bitcoin (2017)

Hơn nữa, Van Wirdum đã trích dẫn một email do Shaolinfry đăng tải trên danh sách gửi thư Bitcoin-dev. Trong đó, Shaolinfry bày tỏ sự phản đối đối với soft fork thợ đào kích hoạt và liệt kê nhiều vấn đề với phương pháp kích hoạt này.

Đầu tiên, nó yêu cầu tỷ lệ băm băm phải được tin tưởng để xác minh trung thực sau khi kích hoạt. Tuy nhiên, trong đợt soft fork BIP66, mặc dù 95% tỷ lệ băm băm cho biết nó đã sẵn sàng, nhưng khoảng một nửa trong số đó thực sự không xác minh các quy tắc nâng cấp và đã khai thác nhầm một khối không hợp lệ [1].

Thứ hai, tín hiệu thợ đào có cơ chế phủ quyết tự nhiên; một lượng nhỏ tỷ lệ băm) có thể phủ quyết ý định nâng cấp của nút , ngăn chặn bất kỳ ai nâng cấp. Cho đến nay, soft fork đã sử dụng một hệ sinh thái khai thác tương đối tập trung, với chỉ một số ít các nhóm khai thác tạo ra các khối hợp lệ. Khi chúng ta chuyển sang một hệ sinh thái khai thác phi tập trung hơn, chúng ta có thể ngày càng bị cản trở bởi "quán tính nâng cấp", điều này có thể phủ quyết phần lớn nâng cấp.

—— Shaolinfry, danh sách gửi thư Bitcoin-dev (2017)

Shaolinfry cũng chỉ ra một hiểu lầm phổ biến về tín hiệu thợ đào: Có một cho rằng rộng rãi rằng chúng là một công cụ để thợ đào quyết định có nên nâng cấp giao thức hay không, chứ không phải là một hành động giúp phối hợp nâng cấp. Do sự hiểu lầm này, thợ đào cũng có thể cảm thấy bắt buộc phải công khai bày tỏ quan điểm của họ về một soft fork, như thể điều này sẽ làm tăng thêm độ tin cậy cho đề xuất của họ.

Nói một cách đơn giản, đề xuất của UASF là một "ngày tín hiệu" mà tại đó nút bắt đầu thực thi các quy tắc mới cụ thể. Bằng cách này, thợ đào không cần phải hành động tập thể để phối hợp nâng cấp; thay vào đó, họ có thể kích hoạt nâng cấp trước ngày tín hiệu, miễn là đã có đủ số khối cho biết họ đã sẵn sàng.

Đề xuất của tôi là kết hợp những ưu điểm của cả hai. Vì soft fork do người dùng kích hoạt yêu cầu một khoảng thời gian chuẩn bị tương đối dài trước khi kích hoạt, chúng ta có thể kết hợp BIP9 để cung cấp tùy chọn kích hoạt phối hợp tỷ lệ băm(sẽ nhanh hơn), và cũng thêm tùy chọn kích hoạt chậm hơn vào ngày báo hiệu. Trong cả hai trường hợp, chúng ta đều có thể tận dụng hệ thống cảnh báo trong BIP9. Thay đổi này tương đối đơn giản; chỉ cần thêm tham số "Thời gian kích hoạt", tham số này sẽ thay đổi trạng thái BIP9 của soft fork thành "LOCKED_IN" trước ngày hết hạn triển khai của BIP9.

—— Shaolinfry, danh sách gửi thư Bitcoin-dev (2017)

Ý tưởng này đã thu hút sự quan tâm đáng kể, nhưng dường như không nhận được sự ủng hộ rộng rãi, làm dấy lên lo ngại rằng nó có thể gây ra sự chia rẽ trong mạng lưới blockchain. Bài viết của Aaron van Wirdum giải thích cách những tranh cãi này cuối cùng đã được giải quyết bằng BIP91 , Bitcoin đề xuất nâng cấp Bitcoin (BIP) do James Hilliard đưa ra.

Hilliard đề xuất một giải pháp phức tạp hơn nhưng thông minh hơn, giúp mọi thứ tương thích: nâng cấp Segregated Witness do đội ngũ phát triển Bitcoin Core đề xuất, bản soft fork BIP148 do người dùng kích hoạt và cơ chế kích hoạt "Thỏa thuận New York". BIP91 của ông có thể ngăn Bitcoin phân tách—ít nhất là trong quá trình kích hoạt Segregated Witness.

— Aaron van Wirdum, “Con đường dài dẫn đến việc chứng kiến ​​biệt lập”, Tạp chí Bitcoin (2017)

Điều này liên quan đến một số yếu tố phức tạp hơn (chẳng hạn như cái gọi là "Đồng thuận New York"), mà BIP cũng phải xem xét. Tôi khuyến khích độc giả đọc toàn bộ bài báo của van Wirdum để hiểu rõ hơn nhiều chi tiết thú vị của câu chuyện này.

5.2.2 Thảo luận sau khi nâng cấp Segregated Witness

Sau khi kích hoạt nâng cấp Segregated Witness, các cuộc thảo luận về cơ chế kích hoạt vẫn tiếp tục. Như Eric Lombrozo đã chỉ ra trong bài thuyết trình của mình tại Breaking Bitcoin và Shaolinfry đã lưu ý (xem mục 5.2.1 ở trên), soft fork do thợ đào kích hoạt không phải là một cơ chế nâng cấp lý tưởng.

Đôi khi chúng ta muốn bổ sung thêm nhiều tính năng cho giao thức Bitcoin. Đây là một câu hỏi triết học lớn mà chúng ta cần tự đặt ra. Chúng ta có nên sử dụng UASF cho nâng cấp tiếp theo không? Hay một phương pháp kết hợp? Kích hoạt tự động thợ đào(phương pháp này) đã lỗi thời. Chúng ta sẽ không còn sử dụng BIP9 nữa.

— Eric Lombrozo, "Thay đổi các quy tắc đồng thuận mà không phá vỡ Bitcoin", Hội nghị Phá vỡ Bitcoin (2017)

Vào tháng 1 năm 2020, Matt Corallo đã gửi email đến danh sách gửi thư Bitcoin-dev, khởi xướng cuộc thảo luận về các cơ chế triển khai soft fork trong tương lai. Ông đã liệt kê năm mục tiêu mà ông cho rằng rất quan trọng đối với nâng cấp. David Harding đã tóm tắt những mục tiêu này trong báo cáo hàng tuần của Bitcoin Optech như sau:

  1. Nếu những thay đổi được đề xuất đối với các quy tắc đồng thuận gặp phải sự phản đối nghiêm trọng, công ty có khả năng từ bỏ nâng cấp.
  2. Có đủ thời gian phối hợp trước khi phần mềm nâng cấp được phát hành, cho phép phần lớn nút kinh tế nâng cấp để thực thi các quy tắc này.
  3. Tốc độ băm của mạng dự kiến ​​sẽ duy trì ở mức tương đương trước và sau khi thay đổi (và trong bất kỳ giai đoạn chuyển đổi nào).
  4. Cố gắng hết sức để ngăn chặn việc tạo ra các khối không hợp lệ theo các quy tắc mới, vì các khối không hợp lệ như vậy sẽ gây ra lỗi trong thống kê xác nhận khối đối với nút không nâng cấp và các máy khách SPV.
  5. Hãy đảm bảo rằng cơ chế bỏ rơi không bị những kẻ gây rối lạm dụng hoặc được sử dụng để trì hoãn nâng cấp dự kiến ​​mà không có vấn đề nào được biết đến.

—David Harding, Bản tin Bitcoin Optech số 80 (2020)

Corallo đề xuất một cơ chế kết hợp giữa soft fork thợ đào kích hoạt và soft fork do người dùng kích hoạt:

Do đó, nói một cách cụ thể hơn, tôi cho rằng rằng phương pháp kích hoạt có thể đóng vai trò là tiền lệ đúng đắn và cân bằng hợp lý các mục tiêu nêu trên nên như sau:

1) Quy trình triển khai BIP 9 tiêu chuẩn, với thời hạn kích hoạt một năm, yêu cầu 95% số thợ đào phải sẵn sàng;

2) Trong trường hợp việc kích hoạt không thành công trong vòng một năm, sẽ có 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 trường hợp hợp lý, hãy cung cấp một lệnh dòng lệnh/tham số cấu hình đơn giản trong các bản phát hành phần mềm triển khai sớm nhất cho phép người dùng chọn quy trình triển khai BIP 8 với khung thời gian 24 tháng để tạo điều kiện kích hoạt Signal Day (đồng thời, các bản phát hành Bitcoin Core mới sẽ tự động kích hoạt thẻ này).

Điều này cung cấp một khoảng thời gian rất dài để áp dụng phương pháp kích hoạt tiêu chuẩn hóa hơn; tuy nhiên, để đảm bảo đạt được mục tiêu 3 đồng thời vẫn đáp ứng mục tiêu 5, cần một khoảng thời gian dài hơn đáng kể. 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 đảm bảo chúng ta không tạo ra tiền lệ tiêu cực mà sau này sẽ phải hối tiếc.

— Matt Corallo, “ Phương pháp kích hoạt Soft Fork hiện đại”, Danh sách gửi thư Bitcoin-dev (2020)

Bản dịch tiếng Trung

5.2.3 Nâng cấp“Taproot” và “Dùng thử nhanh”

Khi Taproot sẵn sàng triển khai vào tháng 10 năm 2020—tức là khi tất cả các chi tiết kỹ thuật liên quan đến các quy tắc đồng thuận của nó đã được thực hiện và được cộng đồng chấp nhận rộng rãi—các cuộc thảo luận về cách triển khai nó bắt đầu diễn ra sôi nổi. Trước đó, những cuộc thảo luận như vậy diễn ra khá lặng lẽ.

Lượng lớn đề xuất liên quan đến cơ chế kích hoạt bắt đầu xuất hiện, và David Harding đã tóm tắt những đề xuất này trong Bitcoin Wiki . Trong bài viết của mình, ông đã giải thích một số đặc tính của BIP8, vốn đã trải qua những thay đổi vào thời điểm đó để trở nên linh hoạt hơn:

Khi tài liệu này được tạo ra, BIP8 dựa trên những bài học kinh nghiệm từ năm 2017. Một thay đổi lớn sau BIP 9+148 là thước đo thời gian cho việc kích hoạt bắt buộc là Block Height, thay vì thời gian trung bình đã trôi qua; thay đổi lớn thứ hai là việc kích hoạt bắt buộc là một tham số boolean có thể được chọn khi thiết lập các tham số kích hoạt cho soft fork trong quá trình triển khai ban đầu, và cũng có thể được cập nhật trong các lần triển khai tiếp theo.

BIP8, không yêu cầu kích hoạt bắt buộc, rất giống với BIP9 (có cơ chế bit phiên bản với thời gian chờ và độ trễ). Sự khác biệt chính duy nhất là BIP8 sử dụng Block Height, trong khi BIP9 sử dụng giá trị trung vị của các lần trước. Cài đặt này cho phép các lần thử nâng cấp thất bại (nhưng có thể thử lại).

BIP8 với cơ chế kích hoạt bắt buộc cuối cùng sẽ có một giai đoạn báo hiệu bắt buộc, trong đó tất cả các khối được tạo ra phải tuân thủ các quy tắc của nó — chúng phải cho biết rằng chúng đã sẵn sàng kích hoạt lần soft fork— điều này sẽ cho phép soft fork tương tự được kích hoạt trong các phiên bản triển khai trước đó mà không cần kích hoạt bắt buộc. Nói cách khác, nếu một phiên bản phần mềm x đã được phát hành không có cơ chế kích hoạt bắt buộc, trong khi một phiên bản y được phát hành sau đó lại có, và thành công trong việc buộc thợ đào bắt đầu báo hiệu sự sẵn sàng trong cùng một khoảng thời gian, thì cả hai phiên bản phần mềm sẽ bắt đầu thực thi các quy tắc đồng thuận mới cùng một lúc.

Đề xuất BIP8 sửa đổi đủ linh hoạt để thể hiện những ý tưởng khác có vẻ phù hợp với BIP8. Điều này tạo ra một yếu tố chung giúp phân biệt nhiều đề xuất khác nhau.

— David Harding, Đề xuất kích hoạt Taproot, Bitcoin Wiki (2020)

Từ thời điểm này trở đi, cuộc thảo luận trở nên rất gay gắt, đặc biệt là về việc liệu lockinontimeout nên được đặt thành true (nhằm cho phép người dùng kích hoạt soft fork, hay cái mà Harding gọi là "BIP8 với kích hoạt bắt buộc") hay false (nhằm cho phép thợ đào kích hoạt soft fork, hay cái mà Harding gọi là "BIP8 không có kích hoạt bắt buộc").

Trong số các đề xuất được liệt kê, trong đó xuất mang tên "Hãy xem điều gì sẽ xảy ra". Vì một số lý do, đề xuất này không nhận được nhiều sự chú ý cho đến vài tháng sau đó.

Cuộc thảo luận kéo dài bảy tháng, và dường như không thể đạt được sự đồng thuận rộng rãi về cơ chế triển khai nào nên sử dụng. Mọi người chia thành hai phe chính: một số ủng hộ lockinontimeout=true (phe UASF), trong khi những người khác ủng hộ lockinontimeout=true (phe "thử xem có thất bại không, rồi tìm cách khác"). Vì không có lựa chọn nào nhận được sự ủng hộ áp đảo, cuộc tranh luận cứ xoay vòng và dường như không thể tiến triển. Trong đó cuộc thảo luận diễn ra trong phòng chat trực tuyến (IRC), trong kênh có tên "##taproot-activation"; tuy nhiên, vào ngày 5 tháng 3 năm 2021 , mọi thứ đã thay đổi:

 06:42 < harding> roconnor: 有人提议BIP8(3m, false)(为期3 个月,不设强制激活的BIP8)吗?我之前提过这个问题,但我没看到有人回答。 [...]06:43 < willcl_ark_> 应该有,我自己就在想,与此相比,隔离见证的激活机制是非常直接的:直接是LOT=false ,要是没通过,那就来一次UASF 。06:43 < maybehuman> 有趣。如果我没有记错,在这个频道刚刚创建的时候,“Let's see what happens” (就是false,3m)是一个热门的选择。06:44 < roconnor> harding: 我支持。我不知道这有没有价值。根据我对其他人的顾虑的理解,基本上,我认为这会是一个能够得到广泛接受的选择。06:44 < willcl_ark_> maybehuman: 因为每个人都想要这个升级,甚至矿工们也说自己能在大约两周内升级(至少f2pool 是这么说的)06:44 < roconnor> harding: BIP8(3m,false) 加上一个延长的锁定期。06:45 < harding> roconnor: 哦,不错。从我7 个月前笫一次在wiki 上总结这些选项以来,这是我最喜欢的选项。06:45 <@michaelfolkson> UASF 无法发布(true,3m),但是Core 可以发布(false, 3m)06:45 < willcl_ark_> harding: 对我来说它真的像是一个好方法。*如果* 它失败了,那我们可以先想想这是为什么,就不用浪费太多时间。

—— Nhật ký IRC #taproot-activation

Phương pháp"Hãy xem điều gì sẽ xảy ra" này cuối cùng dường như đã chiếm được cảm tình của mọi người. Quá trình này, sau này được mô tả là "Thử nghiệm nhanh" vì thời gian diễn ra ngắn, đã được David Harding giải thích cho cộng đồng rộng lớn hơn trong một email được đăng trên danh sách gửi thư Bitcoin-Dev .

Một phiên bản trước đó của đề xuất này đã được viết hơn 200 ngày trước [3], trong khi mã cơ bản cho taproot đã được hợp nhất vào phần mềm Bitcoin Core hơn 140 ngày trước [4]. Nếu chúng ta "nhanh chóng" bắt đầu từ cùng một thời điểm khi mã được hợp nhất (điều này là không thực tế), chúng ta hoặc đã kích hoạt taproot trong vòng chưa đầy hai tháng hoặc đã cố gắng kích hoạt lại nó hơn một tháng trước.

Tuy nhiên, chúng tôi đã tranh luận kể từ khi bắt đầu thảo luận về các kế hoạch kích hoạt sau Segregated Witness hơn một năm trước và dường như vẫn chưa tiến gần hơn đến giải pháp mà tôi cho rằng là được chấp nhận rộng rãi [5]. Tôi cho rằng một “giải pháp nhanh chóng” là phương pháp để tiến lên phía trước nhanh chóng, hoặc để chấm dứt cuộc tranh luận (điều này sẽ chấm dứt cuộc tranh luận tính đến nếu việc kích hoạt thành công) hoặc để cung cấp cho chúng ta một số dữ liệu thực tế để làm cơ sở cho các đề xuất kích hoạt gốc trong tương lai.

David Harding, danh sách gửi thư Bitcoin-dev

Cơ chế kích hoạt này đã trải qua hai tháng cải tiến và sau đó được phát hành trong phiên bản Bitcoin Core 0.21.1 . Thợ đào nhanh chóng bắt đầu thể hiện sự sẵn sàng lần nâng cấp, do đó thay đổi trạng thái triển khai của họ thành LOCKED_IN ; sau một thời gian yên tĩnh, quy tắc "Taproot" đã được kích hoạt vào giữa tháng 11 năm 2021, bắt đầu từ Block Height709632 .

5.2.4 Cơ chế nâng cấp trong tương lai

Với những vấn đề phát sinh từ soft fork gần đây (SegWit và Taproot), vẫn chưa rõ cách thức triển khai nâng cấp trong tương lai sẽ như thế nào. Bản Speedy Trial đã được sử dụng để triển khai Taproot, nhưng nó được sử dụng vì nó có khả năng thu hẹp khoảng cách giữa hai phe UASF và MASF, chứ không phải vì đó là cơ chế triển khai tốt nhất mà chúng ta biết.

5.3 Rủi ro

Tại bất kỳ fork nào — dù là phân nhánh soft fork hay hard fork, do người dùng kích hoạt hay thợ đào kích hoạt — đều tồn tại rủi ro mạng lưới blockchain bị chia tách trong suốt thời gian kích hoạt. Một sự chia tách kéo dài vài khối có thể gây tổn hại nghiêm trọng đến tâm lý xung quanh Bitcoin và giá của nó. Nhưng quan trọng hơn, nó tạo ra sự nhầm lẫn rất lớn về " Bitcoin là gì". Bitcoin thuộc Chuỗi này hay Chuỗi kia?

Rủi ro khi người dùng kích hoạt soft fork là các quy tắc mới có thể được kích hoạt ngay cả khi phần lớn tỷ lệ băm băm không hỗ trợ chúng. Điều này có thể dẫn đến sự phân tách Chuỗi kéo dài cho đến khi phần lớn tỷ lệ băm băm áp dụng các quy tắc mới. Nếu thợ đào đã khai thác các khối trên Chuỗi bằng cách sử dụng các quy tắc cũ sau khi phân tách, việc chuyển đổi chúng sang Chuỗi sử dụng các quy tắc mới có thể khó khăn. Tuy nhiên, đáng chú ý là một sự kiện ấn tượng (xem phần 9.2.3 ): Vào tháng 3 năm 2013, mạng Bitcoin đã trải qua sự phân tách blockchain dài do một hard fork bất ngờ, nhưng trái ngược với khích lệ này, hai nhóm khai thác lớn đã quyết định từ bỏ các nhánh mà họ đã khai thác để xây dựng lại sự đồng thuận.

Mặt khác, rủi ro khi thợ đào kích hoạt soft fork là thợ đào có thể gửi tín hiệu không chính xác, nghĩa là chiếm tỷ lệ tỷ lệ băm băm thực tế hỗ trợ thay đổi có thể nhỏ hơn so với vẻ bề ngoài. Nếu tỷ lệ băm băm thực tế hỗ trợ thay đổi không chiếm đa số, chúng ta có thể chứng kiến ​​sự phân tách Chuỗi dài hạn tương tự như những trường hợp đã được mô tả trong các chương trước. Vấn đề này, hoặc ít nhất là một vấn đề tương tự, đã xảy ra trong quá trình triển khai BIP66 (xem mục 9.2.4 ), nhưng đã được giải quyết trong vòng sáu khối.

5.3.1 Chi phí chia tách

Jimmy Sone đã thảo luận về chi phí liên quan đến hard fork) tại hội nghị Breaking Bitcoin ở Paris, nhưng nhiều chi phí mà ông đề cập cũng áp dụng cho các sự kiện phân tách Chuỗi do soft fork) thất bại gây ra. Ông nói về " các tác động tiêu cực bên ngoài ", được định nghĩa là chi phí mà người khác phải trả cho hành động của bạn.

Một ví dụ điển hình về “ngoại tác tiêu cực” là nhà máy. Nó có thể mang lại hiệu quả kinh tế—như nhà máy lọc dầu—sản xuất ra một mặt hàng có lợi cho nền kinh tế, nhưng nó cũng tạo ra các ngoại tác tiêu cực, chẳng hạn như ô nhiễm. Đây không chỉ là vấn đề mà tất cả mọi người đều phải trả giá chịu—hoặc là dọn dẹp hoặc là chịu đựng. Nó còn có các hiệu ứng dây chuyền bậc hai và bậc ba, chẳng hạn như lưu lượng giao thông tăng lên do nhà máy cần thêm công nhân. Ngoài ra, có thể có cả động vật hoang dã sống xung quanh nhà máy. Tuy nhiên, đôi khi không phải ai cũng phải gánh chịu chi phí; chỉ một phần dân số—chẳng hạn như những người trước đây sử dụng các con đường xung quanh và động vật hoang dã sống xung quanh nhà máy—phải chịu đựng gánh nặng.

— Jimmy Song, “Chi phí xã hội của hard fork)”, Hội nghị Breaking Bitcoin (2017)

Trong bối cảnh Bitcoin , ông sẽ sử dụng Bitcoin Cash (Bcash) làm ví dụ về các tác động tiêu cực bên ngoài; Bcash là hard fork) của Bitcoin , được tạo ra ngay trước hội nghị Breaking Bitcoin năm 2017. Song cũng phân biệt giữa chi phí một lần và chi phí vĩnh viễn của các nhánh hard fork triển.

Trong nhiều ví dụ về chi phí phát sinh một lần, ông cũng đề cập đến chi phí phát sinh do sàn giao dịch.

Trên thị trường có rất nhiều sàn giao dịch, và tất cả đều phải chịu những chi phí phát sinh lượng lớn. Trước hết, cửa sổ nạp và rút tiền phải tạm ngừng hoạt động trong một hoặc hai ngày vì họ không chắc chắn điều gì sẽ xảy ra. Nhiều sàn giao dịch như vậy đã phải sử dụng kho lạnh do nhu cầu sử dụng Bcash của người dùng. Đây là nghĩa vụ ủy thác tín nhiệm của họ, và họ phải làm như vậy. Bạn cũng phải kiểm toán phần mềm mới. Đây là điều mà chúng tôi tại itbit đã phải làm. Chúng tôi muốn sử dụng Bcash – nhưng bằng cách nào? Chúng tôi có phải tải xuống phần mềm electron cash không? Liệu có phần mềm độc hại không? Do đó, kiểm toán là cần thiết. Có thể mất đến 10 ngày để chúng tôi tìm hiểu xem nó có thực sự hoạt động hay không. Sau đó, chúng tôi lại phải quyết định xem có nên chỉ cho phép rút tiền một lần hay niêm yết loại tiền tệ này. Đối với sàn giao dịch, việc thuyết phục các nhà bán lẻ giao dịch một loại tiền tệ mới không phải là vấn đề đơn giản; nó liên quan đến toàn bộ quy trình lưu trữ lạnh, ký kết hợp đồng, nạp và rút tiền. Hoặc, bạn có thể tổ chức một sự kiện một lần để hoàn trả Bcash cho người dùng, điều này sẽ giải quyết được vấn đề. Nhưng điều đó cũng có những vấn đề riêng. Cuối cùng, dù bạn làm gì đi nữa—cho phép người dùng rút tiền hay niêm yết một loại tiền tệ mới—bạn cũng cần cơ sở hạ tầng mới để vận hành loại tiền tệ mới này, ngay cả khi bạn chỉ cung cấp dịch vụ rút tiền một lần. Phải có cách để hoàn trả tiền cho người dùng. Và bạn cần phải đưa ra thông báo tạm thời, đúng không? Thời gian rất gấp và vấn đề rất cấp bách.

— Jimmy Song, “Chi phí xã hội của hard fork)”, Hội nghị Breaking Bitcoin (2017)

Ông cũng liệt kê các chi phí phát sinh một lần đối với các thương nhân, nhà xử lý thanh toán, phần mềm ví điện tử, thợ đào và người dùng, cũng như các chi phí thường trực như mất quyền riêng tư và rủi ro tái cấu trúc Chuỗi cao hơn.

Trên thực tế, khi xảy ra sự phân tách blockchain, nếu Chuỗi có quy tắc lỏng lẻo hơn mạnh hơn Chuỗi có quy tắc nghiêm ngặt hơn, Chuỗi sẽ diễn ra. Điều này sẽ gây ảnh hưởng nghiêm trọng đến tất cả các giao dịch trên nhánh bị ảnh hưởng. Vì những lý do này, việc tránh phân tách Chuỗi là vô cùng quan trọng.

5.4 Kết luận

Bitcoin đã phát triển và tiến hóa theo thời gian. Trong giai đoạn này, nhiều cơ chế nâng cấp khác nhau đã được áp dụng, và quá trình học hỏi của nó rất nhanh chóng. Khi chúng ta hiểu rõ hơn về phản hồi của mạng lưới, phương pháp ngày càng tinh vi và mạnh mẽ hơn liên tục được phát minh ra.

Để duy trì sự hài hòa trong Bitcoin, soft fork đã được chứng minh là giải pháp tối ưu. Tuy nhiên, một vấn đề lớn vẫn chưa được giải quyết: làm thế nào để triển khai soft fork một cách an toàn mà không gây ra bất hòa?

Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
Thêm vào Yêu thích
Bình luận