Bởi Ruben Somsen
Nguồn: https://gist.github.com/RubenSomsen/a02b9071bf81b922dcc9edea7d810b7c
Bài đăng về danh sách gửi thư Bitcoin ở đây và cuộc thảo luận về podcast ở đây .
giới thiệu
Trong quá trình nghiên cứu gần đây về " SwiftSync " ( bản dịch tiếng Trung ), tôi đã phát hiện ra một lỗi đồng thuận chưa được giải quyết trong BIP30 . Có vẻ như lỗi này không thể được kích hoạt nếu không có quá trình tổ chức lại blockchain từ năm 2010, do đó mức độ nghiêm trọng của nó vẫn còn gây tranh cãi. Máy trạm Bitcoin hiện tại của chúng tôi bao gồm các điểm kiểm tra có từ năm 2013, vì vậy nó được bảo vệ khỏi các đợt tổ chức lại sâu như vậy. Tuy nhiên, nếu tất cả các điểm kiểm tra bị xóa , về mặt lý thuyết, lỗi này có thể bị khai thác.
(Ghi chú của người dịch: "Điểm kiểm tra" là một phương pháp đặc biệt để duy trì sự đồng thuận trong mạng blockchain: phần mềm máy trạm yêu cầu giá trị băm khối ở một độ cao nhất định phải là một giá trị nhất định. Nếu giá trị băm khối kết quả không phải là giá trị này, nó sẽ bị từ chối. Trong mạng blockchain dựa trên Bằng chứng công việc (PoW), phương pháp này có thể được sử dụng để ngăn nút mới tham gia mạng bị dụ vào một blockchain độc hại có thể được tạo ra với chi phí thấp (khi sức mạnh của máy khai thác tăng lên, việc tạo ra các khối có cùng độ khó như các khối lịch sử cũ hơn sẽ ngày càng rẻ hơn). Bất chấp lý do tích cực này, mọi người có xu hướng cho rằng rằng việc cho phép cơ chế này tồn tại có thể trao quá nhiều quyền cho các nhà phát triển máy khách (lo ngại rằng nó sẽ cho phép các nhà phát triển về cơ bản quyết định người dùng blockchain nào sẽ chọn). Do đó, đã có những nỗ lực để loại bỏ cơ chế này trong máy trạm.)
Xét về mặt kiểm tra đồng thuận, BIP30 cũng có phần kỳ lạ, đòi hỏi phải lặp lại toàn bộ tập UTXO, ngay cả khi chúng không liên quan đến dữ liệu đầu vào được sàn giao dịch sử dụng. Điều này không hiệu quả và làm phức tạp đáng kể việc triển khai các phương thức xác minh thay thế (như utreexo, SwiftSync, và có khả năng cũng ảnh hưởng đến các hệ thống dựa trên bằng chứng không kiến thức như ZeroSync). Sẽ rất tốt nếu BIP30 có thể bị khai tử hoàn toàn.
Thay vì nhất thiết phải ủng hộ hành động (tình trạng hiện tại có vẻ khá tốt), tôi hy vọng có thể đề xuất giải pháp cho cả hai vấn đề và bắt đầu thảo luận.
1. Lỗi đồng thuận
BIP30 coi hai giao dịch chồng chéo là ngoại lệ. Giao dịch sau là giao dịch Coinbase Block Height 91880. Khi giao dịch này được xử lý, giao dịch Coinbase Block Height 91722 đã bị ghi đè. Một trường hợp tương tự khác đã xảy ra ở các khối 91812 và 91842.
Vấn đề phát sinh khi blockchain được tổ chức lại giữa các khối 91880 và 91772. Khi chúng ta khôi phục blockchain , đầu ra được tạo trong khối 91880 sẽ bị xóa khỏi bộ UTXO. Do đó, đầu ra bị ghi đè sẽ biến mất hoàn toàn khỏi bộ UTXO. Tuy nhiên, một nút khác chưa từng chứng kiến lần tổ chức lại vẫn giữ lại đầu ra này trong bộ của nó (vì nó chưa từng bị ghi đè). Khi UTXO này được sử dụng hết, Chuỗi fork chuỗi sẽ xảy ra.
Giải pháp A
Chúng tôi có thể đảm bảo rằng việc tổ chức lại không thể diễn ra chính xác giữa các khối 91722 và 91880—nó phải diễn ra sâu trước khối 91722 hoặc nông ngay sau Block Height 91880. Điều này đảm bảo rằng cả các khối đã trải qua việc tổ chức lại lẫn nút mới đều không có kết quả đầu ra có vấn đề này trong bộ UTXO của chúng. Xét đến việc đây là khoảng 160 khối ở độ khó khai thác năm 2010, đây không phải là một hạn chế đáng kể.
Giải pháp B
Khi thảo luận về những phát hiện của tôi với Sjors Provoost, ông ấy chỉ ra rằng việc loại bỏ các điểm kiểm tra hiện đang được xem xét (bản thân nó cũng có thể được coi là một hard fork) cũng là một cơ hội để thay đổi các quy tắc đồng thuận trước các điểm kiểm tra—chúng ta có thể sửa lỗi này bằng cách không xóa giao dịch coinbase khi đạt đến các lần tổ chức lại Block Height 91880 và 91842. Hơn nữa, quan sát của Sjors đặt ra câu hỏi liệu chúng ta có muốn thay đổi các quy tắc đồng thuận khác đã tồn tại trước năm 2013 hay không.
2. Làm cho các kiểm tra tập hợp BIP30 UTXO trở nên lỗi thời
Hiện tại, BIP30 áp dụng từ Khối Genesis cho đến khi BIP34 được kích hoạt (Block Height 227931, tháng 3 năm 2013). Nếu khối này được tổ chức lại, BIP30 sẽ vẫn áp dụng vô thời hạn. BIP34 cũng có những vấn đề riêng, được giải quyết trong " BIP Dọn Dẹp Đồng Thuận "—bạn có thể tự đọc về nó; tôi sẽ không trình bày chi tiết ở đây.
Về mặt kỹ thuật, BIP30 được thiết kế đơn giản để ngăn chặn các đầu ra chưa sử dụng trùng lặp. Nó thực hiện điều này bằng cách kiểm tra mọi mục nhập trong tập UTXO hiện có, và nếu có bất kỳ mục nhập trùng lặp nào, nó sẽ từ chối tạo khối trùng lặp (đó là lý do tại sao nó kém hiệu quả). Hai giao dịch trùng lặp xảy ra vào năm 2010 đã được mã hóa cứng như một ngoại lệ. Theo các quy tắc này, việc sử dụng một đầu ra rồi tạo lại cùng một đầu ra không phải là vi phạm. Tuy nhiên, điều này dường như chưa từng xảy ra.
Câu hỏi cuối cùng cần giải quyết là tại sao BIP34 bị loại bỏ nếu khối 227931 được tổ chức lại. Lý do là nếu không bị loại bỏ, có thể tạo ra các đầu ra vi phạm các quy tắc của BIP34 (đảm bảo tính duy nhất của giao dịch Coinbase) trước khi BIP34 được kích hoạt (đây chính xác là vấn đề mà đề xuất dọn dẹp đồng thuận đang cố gắng giải quyết).
Về lý tưởng, sẽ tốt hơn nếu ngừng hoàn toàn việc kiểm tra BIP30 (đảm bảo rằng nó không còn cần thiết nữa ngay cả khi tổ chức lại khối xảy ra).
Giải pháp
Do không có giao dịch nào bị chồng chéo ngoại trừ hai trường hợp ngoại lệ này, chúng ta có thể thay thế việc kiểm tra bộ UTXO BIP30 kém hiệu quả bằng kiểm tra tính duy nhất của giao dịch Coinbase. Chúng tôi chỉ cần lưu trữ đệm TXID của giao dịch Coinbase và đảm bảo không có giao dịch nào bị chồng chéo trong giao dịch Coinbase. Việc kiểm tra này, kéo dài đến Block Height 227931, chỉ cần khoảng 7MB bộ nhớ đệm. Tuy nhiên, vì BIP34 có thể bị loại bỏ, việc kiểm tra BIP30 có thể tiếp tục vô thời hạn, dẫn đến bộ nhớ đệm liên tục tăng trưởng. Phương pháp như sau.
Ngoài việc kiểm tra tính duy nhất của giao dịch Coinbase, chúng tôi cũng kiểm tra xem nó có xung đột với bất kỳ giao dịch Coinbase nào trong tương lai không (tức là không xung đột với BIP34 và BIP dọn dẹp đồng thuận). Điều này đảm bảo BIP34 có thể được kích hoạt ở Block Height 227931, bất kể có xảy ra tái tổ chức hay không.
Phần kết luận
Trên đây là một số vấn đề liên quan đến BIP30 và các giải pháp khả thi. Bài viết này chỉ mang tham khảo để chúng ta cân nhắc có nên hành động hay không. Xin cảm ơn Antoine Poinsot, Pieter Wuille và Sjors Provoost đã thảo luận trước khi bài viết này được xuất bản.
