Giới hạn sắp xếp lại và xác nhận trễ: Sơ lược về phán quyết cuối cùng
Giới hạn reorg là “giới hạn tổ chức lại”; nói cách khác, “giới hạn sắp xếp lại” hoặc “ngưỡng mềm cuối cùng”.
Theo bất kỳ điều khoản nào trong số này, giá trị xác định giới hạn của máy khách (còn gọi là “nút”) trên mạng Proof-of-Work phi tập trung sẽ sử dụng để phân biệt dữ liệu chuỗi có thể thay đổi và bất biến .
Bây giờ, nếu bạn đang đọc từ “bất biến” ở trên với trực giác hoặc ngụ ý rằng dữ liệu chuỗi khối Proof-of-Work luôn hoàn toàn bất biến, thì trước tiên tôi phải thách thức quan niệm sai lầm phổ biến này.
Các Lời hứa bất biến của Ethereum Classic không nói trực tiếp đến bất kỳ tập hợp cụ thể, đầy đủ hoặc một phần, dữ liệu chuỗi. Thay vào đó, nó nói lên ý định tiếp tục một giao thức mạng và cơ sở dữ liệu như được thiết kế đến vô tận. Và trên thực tế, giao thức dựa trên Proof-of-Work được mô tả trong Yellow Paper nổi tiếng như là đặc điểm kỹ thuật cho Ethereum (và bởi Ethereum Classic), phụ thuộc sâu vào việc không có bất kỳ nút nào giả định về tính lâu dài của bất kỳ dữ liệu chuỗi nào.
Bởi vì các nút phải sử dụng các quy tắc đồng thuận được chia sẻ để đến các trạng thái dữ liệu chuỗi tương đương một cách độc lập, các quy tắc này được giới hạn trong phạm vi của các biến tồn tại dưới dạng các đặc điểm của chính dữ liệu chuỗi và có thể được xác thực và tạo bằng các triển khai chức năng có nguồn gốc từ đặc tả. Giá trị như vậy sẽ bao gồm total difficulty, mix hashvà state root.
Các xác nhận đặc trưng này của dữ liệu chuỗi như là điều kiện duy nhất mà theo đó các nút đến trạng thái dữ liệu chuỗi chung cho phép Khả năng chịu lỗi Byzantine phi tập trung của mạng. Các nút không bao giờ bị ép buộc phải phụ thuộc vĩnh viễn vào bất kỳ nối ngang hàng (peer), tập hợp kết nối ngang hàng nào hoặc hiểu biết tạm thời về trạng thái mạng. Các nút có thể bị lừa trong một phút hoặc thậm chí một tuần, nhưng về lâu dài, và được cung cấp các điều kiện tiên quyết về mạng được xác định rõ ràng (thường chủ yếu là các peers và thợ đào nhân từ), họ chắc chắn đi đến sự thật chung: đồng thuận.
Giới hạn sắp xếp lại (Reorg caps)
Giới hạn sắp xếp lại là các biến ngoài giao thức (không được định nghĩa trong giao thức) mà các nút có thể sử dụng để đưa ra các giả định tùy ý về tính lâu dài của trạng thái dữ liệu chuỗi. Một lần nữa, điều này sẽ đại diện cho một giả định được thực hiện bên ngoài các quy tắc đồng thuận. Và xa hơn nữa, như chúng ta sẽ thấy, trên thực tế có thể mâu thuẫn trực tiếp với các quy tắc đồng thuận của giao thức.
Giả sử Node A có giới hạn reorg là 3.000 khối. Điều này có nghĩa là nếu nút tin rằng số đầu chuỗi mới nhất là 10.000, thì Nút A sẽ không muốn tuân theo bất kỳ chuỗi hợp lệ nào có “tổ tiên chung” ở khối 6.999 hoặc thấp hơn — ngay cả khi chuỗi “mới” đó dài 100.000 khối , với tổng độ khó cao hơn 10000000x và hoàn toàn hợp lệ theo các quy tắc đồng thuận liên tiếp khối do đặc điểm kỹ thuật xác định.
Bây giờ, giả sử Node B có cùng giới hạn reorg là 3.000 khối. Nhưng Node B xảy ra ở vị trí vật lý bên cạnh một người khai thác và lắng nghe và nhập một khối được đánh số 10,001 trước khi Node A thực hiện. Sau đó, bằng một phép lạ hay bi kịch nào đó, chuỗi dài 100.000 được công bố và cả Nút A và Nút B đều nghe về ứng cử viên chuỗi mới này cùng một lúc. Chuỗi mới tình cờ có một tổ tiên chung trên cả hai nút A và B tại khối 7.000.
Trong trường hợp này, Nút A, có khối đầu là 10.000 — đặt tổ tiên chung trong giới hạn khôi phục là 3.000 (10.000–3.000 = 7.000) — sẽ cho phép tổ chức lại và tổ chức lại cơ sở dữ liệu khối của nó để tải xuống khối mới hợp lệ , chuỗi khối 100.000. Mặt khác, nút B đã nhập khối 10,001 (là khối hoàn toàn hợp lệ, mặc dù rõ ràng là kém hơn khối thứ 100.000 được phát đi trong mạng lưới), sẽ từ chối việc tổ chức lại, vì giới hạn tổ chức lại 3.000 khối của nó ngăn không cho nó thay đổi bất kỳ khối dưới khối 7.001. Node B hiện không có khả năng đồng bộ hóa với chuỗi khối 100.000 và sẽ phải chịu sự thất bại đồng thuận này…
Đó là, trừ khi nhà điều hành của Node B quyết định tin tưởng vào tin đồn trên Twitter và xóa dữ liệu chuỗi đã được tải xuống của nút và thử đồng bộ hóa lại với mạng. Khi nào và nếu như vậy, nó có thể có thể để xác nhận và nhập chuỗi khối 100.000, và đạt được sự đồng thuận với Node A. Nó sẽ thất bại trong lần thử đồng bộ hóa thứ 2 này (một lần nữa) nếu kết nối ngang hàng hoặc các kết nối ngang hàng mà nó kết nối với nó báo cáo cho nó chuỗi khối 10.001 ngắn hơn trước khi nó có thể tìm hiểu hoặc xử lý chuỗi khối 100.000. Trong trường hợp đó, nhà điều hành nút phải tham khảo ý kiến của họ một lần nữa…
Vì vậy, như đề cập ở trên, vấn đề về sự đồng thuận của Node B có thể được giải quyết (ít nhất là có thể xảy ra và tạm thời) bằng cách ghi đè theo cách thủ công “chế độ xem” mạng chủ quan và tạm thời của nó, giới hạn reorg được hiểu là giá trị “độ mềm cuối cùng”.
Giới hạn sắp xếp lại trên lý thuyết và thực tế
Về lý thuyết, KHÔNG có đặc điểm kỹ thuật hoặc sự cho phép nào đối với giới hạn tổ chức lại trong giao thức chuỗi khối PoW của Ethereum hoặc Ethereum Classic. Như đã nêu trên, về mặt lý thuyết, chúng mâu thuẫn với các giả định cơ bản của giao thức đồng thuận.
Trong thực tế, chúng tồn tại. OpenEthereum rõ ràng có mức giới hạn 3.000. Và trên thực tế, vào ngày 1 tháng 8 năm 2020, giá trị tác động đến sự đồng thuận phi giao thức này đã gây ra sự phân tách chuỗi (hoặc chia tách!), Với các nút OpenEthereum không thể đạt được trạng thái mạng đã được xác thực giao thức đồng thuận chính xác khi một thợ đào trên Ethereum Classic phát đi phân đoạn chuỗi hợp lệ dài 3.671 khối.
Giới hạn reorg được gọi là FullImmutabilityThreshold(đối với cấu hình đồng bộ nhanh và đầy đủ) và LightImmutabilityThreshold(đối với cấu hình LES) cũng tồn tại trong Core-Geth và ethereum/go-ethereum, được đặt lần lượt là 90.000 và 30.000. Các giá trị này, liên quan đến sự đồng thuận dữ liệu chuỗi, được giả định và cố ý thiết kế để "cao không tưởng", thể hiện giả định do nhà phát triển cấp rằng chúng không bao giờ nên thực sự được sử dụng trong giao thức đồng bộ. Những giá trị này tồn tại để tạo điều kiện thuận lợi cho tính thực tiễn của việc tối ưu hóa cơ sở dữ liệu, cụ thể là việc tách dữ liệu chuỗi thành hai cơ sở dữ liệu, một cơ sở dữ liệu được gọi là “Ancient Store”, là một kho dữ liệu bất biến được thiết kế để lưu trữ dữ liệu chuỗi lưu trữ với hiệu quả cực cao, tối ưu hóa việc sử dụng đĩa lưu trữ và nhập/xuất (IO). Các khối có số lượng giảm xuống dưới giới hạn này (giả sử, khối 909.999 của chuỗi 1.000.000 khối) được cho là an toàn để di chuyển đến “Ancient Store”, do đó tối ưu hóa việc sử dụng đĩa lưu trữ của chương trình.
Nếu một người khai thác phát đi một phân đoạn chuỗi khối 100.000 “mới”, hợp lệ và khó chiếm ưu thế trước sự ngạc nhiên của mạng lưới, thì cả OpenEthereum và Core-Geth (và ethereum/go-ethereum) sẽ dễ bị tấn công. Bằng thuật toán độ khó liên quan đến sự đồng thuận, một phân đoạn 90.000 khối sẽ mất khoảng 2 tuần khai thác để tạo ra.
Giới hạn sắp xếp lại và độ trễ xác nhận
Giới hạn của sắp xếp lại thường được liên kết với các giá trị mà người dùng gặp phải với các sàn giao dịch tiền điện tử đó là Độ trễ xác nhận. Các sàn giao dịch sử dụng độ trễ xác nhận để quyết định thời điểm mà họ cảm thấy “an toàn” để cuối cùng cho phép gửi và rút tiền từ tài khoản trong khi chờ xử lý giao dịch với một chuỗi nhất định. Khi một giao dịch được xử lý bởi mạng chuỗi, nếu việc tổ chức lại chuỗi tiếp theo với mức độ lớn bên trong sự chậm trễ xác nhận của họ xảy ra, thì sàn giao dịch có thể chỉ cần hủy bỏ giao dịch ở phía Exchange và nhắc người dùng thử lại mà không mất gì đáng kể, họ cũng như thay mặt cho người dùng của họ.
Độ trễ xác nhận được thực hiện bởi một sàn giao dịch thể hiện những rủi ro đo lường giả định của họ liên quan đến chuỗi. Một Sàn giao dịch lành mạnh và cạnh tranh sẽ sử dụng nhiều số liệu thời gian thực khác nhau (ví dụ: tỷ lệ băm, số lượng nút, giá trị các cặp giao dịch, thông lượng giao dịch, phương sai lịch sử,...) Cho bất kỳ chuỗi nhất định nào để tạo ra bản trình bày thích ứng và chính xác về rủi ro đo lường dự đoán của họ với chuỗi đó; một số chuỗi muốn cạnh tranh để giảm giá trị rủi ro hơn vì họ muốn cạnh tranh người dùng bằng cách cung cấp dịch vụ “linh hoạt”, trong khi các chuỗi khác chọn lập trường thận trọng hơn.
Giới hạn sắp xếp lại có thể cản trở việc triển khai các thông số kỹ thuật đồng thuận của mạng bằng cách thực thi tính bất biến đối với các phân đoạn chuỗi tùy ý. Sự chậm trễ xác nhận, như giới hạn sắp xếp lại, là những quyết định chủ quan về tính cuối cùng. Tuy nhiên, không giống như giới hạn sắp xếp lại, sự chậm trễ xác nhận chi phối hành vi có chủ quyền ngoài chuỗi (ví dụ: thanh toán fiat cho một lần rút tiền), trong khi giới hạn sắp xếp lại nút có thể ảnh hưởng đến mạng trên chuỗi bao gồm cả trạng thái, hành vi.
Câu hỏi thường gặp
Độ trễ xác nhận của sàn giao dịch và giới hạn sắp xếp lại của máy khách sẽ hợp lực để ngăn chặn các cuộc tấn công 51%?
Không. Đầu tiên, chúng tôi không thể mong đợi, chứ chưa nói đến việc khuyến khích, tất cả các Sở giao dịch chấp nhận cùng một sự chậm trễ xác nhận. Thứ hai, như đã mô tả ở trên, không thể thực hiện giới hạn sắp xếp lại ở cấp độ mạng , vì các nút được phân cấp và cơ chế đồng thuận phụ thuộc vào khả năng của mỗi nút sử dụng các thuật toán đồng thuận giống nhau một cách độc lập và không đồng bộ để đạt đến cùng một trạng thái chuỗi. Máy khách hàng (các nút) triển khai các giới hạn khôi phục có thể hành động đưa ra một mối đe dọa riêng đối với chính họ và sức khỏe mạng tổng thể. Mặt khác, Giá trị số lần xác nhận là một cách tuyệt vời để sàn giao dịch (và tất cả mọi người!) Giảm thiểu rủi ro. Giới hạn sắp xếp lại trong máy khách không giảm thiểu rủi ro: họ làm tăng nó bởi vì tiềm năng ngăn cản và cấm các chức năng đồng thuận cần thiết.
Giới hạn sắp xếp lại có thể được thực hiện dưới dạng giá trị cấu hình nếu chúng ta sử dụng hard fork?
Không, vâng… nhưng không, chắc chắn là không.
Bạn có thể viết một lỗi phần mềm khiến một nút bắt đầu sử dụng một giới hạn sắp xếp lại nhất định khi nó thấy một khối (số) hard fork nhất định có sẵn. Và về mặt lý thuyết, bạn có thể viết mã cho các máy khách để tất cả chúng sử dụng cùng một giá trị giới hạn và kích hoạt nó ở cùng một số hard fork.
Nhưng bạn không thể yêu cầu tất cả các nút truy cập và xử lý cùng một trạng thái mạng cùng một lúc, có nghĩa là mặc dù chúng sẽ sử dụng cùng một giá trị giới hạn bắt đầu từ cùng một số kích hoạt, chúng sẽ không nhất thiết phải sử dụng logic đó theo những cách đồng nhất với nhau. Logic có thể được thực hiện cho nút, nhưng không phải mạng.
Tôi/chúng tôi nên sử dụng giá trị trì hoãn xác nhận nào?
ETC Labs thường được yêu cầu tư vấn cho các Sàn giao dịch trong việc quyết định số xác nhận mà họ nên sử dụng cho Ethereum Classic. Chúng tôi không bao giờ cung cấp một con số. Đó không phải là quyết định của chúng tôi: đó là giá trị đại diện trực tiếp cho sự đo lường rủi ro mong muốn và khả năng đánh giá rủi ro của một sàn giao dịch. Công việc của chúng tôi là đảm bảo chuỗi và mạng hoạt động như được thiết kế và làm những gì có thể để đảm bảo thông tin về thiết kế và giao thức có thể truy cập và có thể thực hiện được. Nhưng công việc của chúng tôi không thể (và không nên) là chỉ cho bất kỳ ai cách sử dụng chuỗi khối, mà chúng tôi chỉ giúp người dùng — cả tổ chức và cá nhân — đưa ra quyết định sáng suốt.
Liên quan
Điều cần thiết là chuỗi dài nhất luôn được coi là chuỗi hợp lệ. Các nút đã có mặt có thể nhớ rằng một nhánh đã có trước và được thay thế bằng nhánh khác, nhưng sẽ không có cách nào để thuyết phục những người không có mặt về điều này. Chúng ta không thể có các giao dịch phụ của các nút bám vào một nhánh mà họ nghĩ nó là trước, những nút khác nhìn thấy nhánh khác trước và những nút khác tham gia sau và không bao giờ thấy điều gì đã xảy ra. Cuộc bỏ phiếu bằng chứng công suất CPU phải có tiếng nói cuối cùng. Cách duy nhất để mọi người giữ vững lập trường là tin rằng chuỗi dài nhất luôn là chuỗi hợp lệ, bất kể điều gì. https://satoshi.nakamotoinsairs.org/emails/cryptography/6/
Ban đầu được xuất bản tại http://github.com.
— — — — — — — — — — — — — — — — — — — — — -
Tham gia thảo luận và cập nhật tin tức mới nhất trên các kênh chính thức của chúng tôi:
- Facebook: facebook.com/EthereumClassicVietnam/
- Telegram: t.me/ETCVietnam
- Twitter: twitter.com/etcvietnam
- Medium: medium.com/@ETCVietnam
