Lưu ý của biên tập viên: Bài viết này đến từLưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ethfans) vitalik, tác giả Vitalik Buterin, in lại với sự cho phép của Odaily.

tiêu đề phụ

Hard Fork, Soft Fork, Mặc định và Bắt buộc

Hình dưới đây có thể minh họa loại fork:

Mô tả hình ảnh

Bên trái của hình là hard fork hai chiều và bên phải là từ lớn đến nhỏ: hard fork mở rộng nghiêm ngặt, thỏa thuận ban đầu, soft fork

• Dưới đây là một số ưu điểm thường được trích dẫn của soft fork và hard fork.
  

• Các nhánh cứng giúp các nhà phát triển linh hoạt hơn khi thực hiện nâng cấp giao thức, vì họ không cần phải cẩn thận để đảm bảo các quy tắc mới.

• Các nhánh mềm thuận tiện hơn cho người dùng vì người dùng không cần nâng cấp để tiếp tục sử dụng chuỗi khối.

• Một soft fork ít có khả năng dẫn đến sự phân tách chuỗi khối.

Soft fork chỉ yêu cầu sự đồng ý của người khai thác/người xác thực (ngay cả khi người dùng vẫn sử dụng quy tắc cũ, nhưng nếu các nút sử dụng quy tắc mới, thì chỉ những thứ hợp lệ theo quy tắc mới mới được đưa vào chuỗi); hard fork yêu cầu người dùng chọn đồng ý.

Ngoài ra, một trong những lời chỉ trích chính về hard fork là hard fork bị "ép buộc". Sự ép buộc được đề cập ở đây không phải là vũ lực vật chất, mà là sự ép buộc thông qua các hiệu ứng mạng. Tức là nếu mạng thay đổi quy tắc từ A sang B, cho dù cá nhân bạn thích A, nếu đa số người dùng khác thích B và chuyển sang B, thì bạn phải chuyển sang B để có thể vào mạng giống như mọi người, bất chấp Các Cá nhân của bạn không đồng ý với sự thay đổi.

1.

Những người ủng hộ hard fork thường bị chế giễu là đang cố gắng đạt được "sự mua lại ác ý" của mạng và "buộc" người dùng tham gia cùng họ. Ngoài ra, nguy cơ chia tách chuỗi khối khiến kế hoạch hard fork được dán nhãn "không an toàn".

Ý kiến ​​​​cá nhân của tôi là những lời chỉ trích này là không đúng chỗ và trong nhiều trường hợp đặt xe trước ngựa. Điểm này không dành riêng cho Ethereum, Bitcoin hay bất kỳ chuỗi khối nào khác; nó bắt nguồn từ bản chất phổ biến của các hệ thống này và áp dụng cho bất kỳ hệ thống nào. Hơn nữa, lập luận bên dưới chỉ áp dụng cho các thay đổi giao thức gây tranh cãi, tức là khi đa số thành viên của ít nhất một thành phần cộng đồng (thợ mỏ/người xác thực và người dùng) không chấp nhận thay đổi; nếu thay đổi giao thức không gây tranh cãi, thì thay đổi đó thường có thể được thực hiện một cách an toàn, cho dù fork được thực hiện theo cách nào.

Đầu tiên, hãy thảo luận về vấn đề cưỡng chế. Cả hard fork và soft fork đều có thể thay đổi giao thức theo cách mà một số người dùng có thể không thích; nếu thay đổi không được hỗ trợ 100%, thì mọi thay đổi giao thức đều gặp phải vấn đề bị thực thi. Hơn nữa, gần như không thể tránh khỏi rằng trong mọi trường hợp, ít nhất một số người phản đối các thay đổi giao thức sẽ từ bỏ các quy tắc giao thức ưa thích của họ vì họ muốn phù hợp với đa số thành viên chú trọng nhiều hơn vào hiệu ứng mạng. Do đó, cả hai loại fork đều bắt buộc theo nghĩa hiệu ứng mạng.

Tuy nhiên, có một sự khác biệt cơ bản giữa hard fork và soft fork: hard fork cho người dùng cơ hội lựa chọn, trong khi soft fork không cho phép người dùng "chọn". Người dùng muốn tham gia chuỗi hard fork phải cài đặt gói phần mềm tự thực hiện các quy tắc fork và những cơ sở người dùng không đồng ý với quy tắc thay đổi nhiều hơn những gì họ coi trọng các hiệu ứng mạng về mặt lý thuyết có thể chỉ cần ở lại chuỗi cũ — trên thực tế, theo cách này các sự kiện đã xảy ra.

Mô tả trên áp dụng như nhau cho các hard fork mở rộng nghiêm ngặt và các hard fork hai chiều. Tuy nhiên, trong một đợt fork mềm, một khi fork được fork thành công, chuỗi khối trước fork không còn tồn tại. Do đó, các nhánh mềm rõ ràng thiên về thể chế đối với sự chấp nhận bắt buộc hơn là từ bỏ và các nhánh cứng thì ngược lại về mặt này. Quan điểm đạo đức của riêng tôi khiến tôi ủng hộ sự thảnh thơi hơn là ép buộc, mặc dù những người khác có thể không đồng ý (lập luận phổ biến nhất là các hiệu ứng mạng thực sự quan trọng và sự tồn tại của "một đồng xu" là rất quan trọng, mặc dù các phiên bản nhẹ nhàng hơn cũng tồn tại).

Bên cạnh cuộc thảo luận ở trên, nếu tôi phải đoán tại sao các nhánh mềm thường được coi là "ít bắt buộc hơn" so với các nhánh cứng, thì tôi sẽ nói rằng đó là vì một nhánh cứng có cảm giác như nó "buộc" người dùng cài đặt bản cập nhật phần mềm và ngã ba mềm người dùng không "nhất thiết" làm bất cứ điều gì. Tuy nhiên, trực giác này là sai lầm: điều quan trọng không phải là liệu người dùng cá nhân có phải trải qua bước quan liêu đơn giản là nhấp vào nút "tải xuống" hay không, mà là liệu người dùng có cần bị buộc phải chấp nhận các thay đổi quy tắc giao thức mà họ không muốn chấp nhận hay không. Được đo lường theo tiêu chuẩn này, các nhánh mềm và cứng cuối cùng là bắt buộc, trong khi các nhánh cứng tốt hơn một chút trong việc duy trì sự tự do của người dùng.

Bây giờ, hãy xem xét các đợt fork gây nhiều tranh cãi, đặc biệt là những đợt mà tùy chọn của người khai thác/người xác thực xung đột với tùy chọn của người dùng. Có ba kịch bản ở đây: (i) một hard fork hai chiều, (ii) một hard fork mở rộng nghiêm ngặt và (iii) cái gọi là "soft fork do người dùng kích hoạt" (UASF). Loại thứ tư là nơi những người khai thác kích hoạt các nhánh mềm mà không có sự đồng ý của người dùng; chúng ta sẽ thảo luận về điều đó sau.

Đầu tiên, một hard fork hai chiều. Trong trường hợp tốt nhất, tình hình là đơn giản. Hai đồng tiền này được giao dịch trên thị trường và các nhà giao dịch xác định giá trị tương đối của hai loại tiền này. Từ trường hợp ETC/ETH, chúng tôi có nhiều bằng chứng cho thấy các công ty khai thác rất có thể chỉ cần phân phối sức mạnh tính toán của họ theo tỷ lệ giá tiền xu để tối đa hóa lợi nhuận của họ, bất kể hệ tư tưởng của họ là gì.

Ngay cả khi hệ tư tưởng của một số công cụ khai thác nghiêng về bên này hay bên kia, rất có thể sẽ có đủ những người khai thác khác sẵn sàng phân xử sự không phù hợp giữa giá và tỷ lệ băm để đưa cả hai vào hàng. Giả sử một số người khai thác cố gắng thành lập một nhóm không khai thác trên một chuỗi nhất định, không gian chênh lệch giá sẽ tạo ra động cơ để mọi người không làm như vậy.

Có hai trường hợp cạnh ở đây. Khả năng đầu tiên là giá trị khai thác đã giảm do giá giảm, nhưng độ khó chưa giảm xuống mức phù hợp do thuật toán điều chỉnh độ khó không hiệu quả, lúc này việc khai thác trở nên thua lỗ và sẽ không có thợ mỏ nào sẵn sàng để mất tiền.Tiếp tục đẩy toàn bộ chuỗi về phía trước cho đến khi khó khăn trở lại trạng thái cân bằng. Đây không phải là trường hợp của Ethereum, nhưng nó có thể là trường hợp của Bitcoin. Do đó, chuỗi thiểu số rất có thể sẽ không bao giờ bắt đầu. Lưu ý rằng tình huống này tốt hay xấu phụ thuộc vào cảm nhận của bạn về ép buộc và ly khai; bạn có thể suy luận từ những gì tôi đã viết ở trên rằng cá nhân tôi nghĩ rằng loại thuật toán điều chỉnh độ khó gây thù địch với các chuỗi thiểu số này là không tốt.

Kịch bản thứ hai là chuỗi lớn hơn có thể tấn công 51% chuỗi nhỏ hơn nếu chênh lệch quá lớn. Ngay cả với tỷ lệ phân chia 10:1 ETH/ETC, điều đó đã không xảy ra; vì vậy nó chắc chắn không phải xảy ra. Tuy nhiên, nếu những người khai thác trên chuỗi lớn thích ép buộc hơn là ly khai và hành động theo sở thích của họ, thì kịch bản tấn công 51% luôn có thể xảy ra.Tiếp theo, hãy xem xét việc mở rộng hard fork một cách nghiêm ngặt. SEHF (viết tắt của Strict Extended Hard Fork) có đặc tính là chuỗi trước fork vẫn có hiệu lực theo các quy tắc sau fork, vì vậy nếu chuỗi fork rẻ hơn chuỗi không fork thì nó sẽ có giá thấp hơn chuỗi sau fork. chuỗi không rẽ nhánh. Chuỗi không rẽ nhánh có sức mạnh tính toán thấp hơn, do đó, chuỗi không rẽ nhánh cuối cùng sẽ được chấp nhận là chuỗi dài nhất bởi các quy tắc máy khách của chuỗi gốc và quy tắc máy khách rẽ nhánh, trong khi chuỗi rẽ nhánh "”。

sẽ bị xóa sổ

Một fork như vậy có một nhược điểm cố hữu, bởi vì khả năng chuỗi fork bị hủy diệt sẽ được phản ánh vào giá, khiến giá giảm xuống, khiến chuỗi có nhiều khả năng bị hủy diệt hơn... Theo tôi, lập luận này rất mạnh mẽ, vì vậy Bất kỳ cuộc tranh cãi nào The fork of nên là một hard fork hai chiều, không phải là một phần mở rộng nghiêm ngặt.Các nhà phát triển Bitcoin Unlimited đề xuất áp dụng sau forkHardfork thủ công hai chiều

để giải quyết vấn đề này, nhưng một lựa chọn tốt hơn là thông qua tính hai chiều tích hợp; ví dụ: trong trường hợp của Bitcoin, các quy tắc có thể được thêm vào để không cho phép một số opcode không được sử dụng và sau đó thao tác chứa opcode này có thể được thực hiện trên chuỗi không phân nhánh giao dịch, do đó theo quy tắc fork, chuỗi không fork sẽ bị coi là không hợp lệ vĩnh viễn kể từ đó. Trong trường hợp của Ethereum, hầu hết tất cả các hard fork đều tự động hai chiều do các chi tiết khác nhau về cách hoạt động của tính toán trạng thái. Các chuỗi khối khác có thể có các thuộc tính khác nhau do sự khác biệt về cấu trúc.

Loại fork cuối cùng được đề cập ở trên là soft fork do người dùng kích hoạt. Trong UASF (viết tắt của User Activated Soft Fork), người dùng chuyển sang quy tắc soft fork mà không có sự đồng thuận của thợ mỏ; họ mong đợi thợ mỏ tự động đồng ý với thay đổi quy tắc vì lợi ích kinh tế. Nếu nhiều người dùng không triển khai UASF, thì đồng xu sẽ bị chia tách, điều này sẽ dẫn đến tình huống tương tự như một hard fork mở rộng quy mô nghiêm ngặt, ngoại trừ - và đây là phần thực sự thông minh và lệch lạc của khái niệm - gây bất lợi nghiêm trọng trong một quy mô nghiêm ngặt. hard fork mở rộng quy mô "Rủi ro hủy diệt" của các chuỗi được chia tách ở đây thiên về các chuỗi được chia tách trong UASF. Ngay cả khi UASF cung cấp các tùy chọn, nó sẽ khai thác sự bất đối xứng về kinh tế để làm cho các đợt phân tách có nhiều khả năng thành công hơn (mặc dù xu hướng này không phải là tuyệt đối; nếu UASF quyết định không phổ biến, thì nó sẽ không thành công và sẽ dẫn đến sự phân tách chuỗi khối).

Tuy nhiên, UASF là một mối nguy hiểm. Ví dụ: giả sử các nhà phát triển của dự án muốn tạo một bản vá UASF để chuyển đổi một opcode chưa được sử dụng trước đó chấp nhận tất cả các giao dịch thành một opcode chỉ chấp nhận các giao dịch tuân theo một số quy tắc mới, ngay cả khi gây tranh cãi về mặt chính trị hoặc kỹ thuật hoặc Người khai thác không thích nó . Những người khai thác có một cách thông minh và xảo quyệt để chống lại: họ có thể đơn phương thực hiện một đợt ngã ba mềm do người khai thác kích hoạt, khiến tất cả các giao dịch sử dụng chức năng do đợt ngã ba mềm tạo ra đều thất bại.

• Giả sử chúng ta có ba bộ quy tắc:

• Nguyên tắc ban đầu, trong đó opcode X luôn hợp lệ.

• Quy tắc trong đó opcode X chỉ hợp lệ nếu phần còn lại của giao dịch tuân thủ quy tắc mới

Opcode X luôn là quy tắc không hợp lệ.

Lưu ý rằng (2) là về nhánh mềm của (1) và (3) là về nhánh mềm của (2). Theo giả thuyết, có áp lực kinh tế mạnh mẽ ủng hộ (3) và soft fork không thể đạt được mục tiêu của nó.