Tác giả gốc: parithosh

Nguồn ban đầu: note.ethereum.org

bản tóm tắt

bản tóm tắt

tóm tắt

tóm tắt

Mạng thử nghiệm hợp nhất Kintsugi đã gặp phải một loạt sự cố trong vài tuần đầu hoạt động, làm lộ ra một số lỗ hổng trên nhiều máy khách. Vấn đề chủ yếu là do một fuzzer được phát triển bởi nhà phát triển Marius, nhằm mục đích tạo ra các khối thú vị và quảng bá các khối trong mạng.

một khối như thế nàyblockHash(khối băm) được thay thế bằngparentHash(băm khối mẹ).engine_executePayloadcó tất cả các khối xây dựng và khối xây dựngblockHashTất cả các thông số cần thiết. Máy khách EL (lớp thực thi) nên xây dựng các khối dựa trên các tham số này vàblockHashchứng thực. Khối cụ thể này đã thất bại trong kiểm tra của Geth, nhưng đã vượt qua kiểm tra của Nethermind và Besu. Khối đã được xác thực không chính xác trong Nethermind do các vấn đề về bộ nhớ đệm, trong khi Besu hoàn toàn không có kiểm tra nào như vậy. Do đó, khối được đề xuất bởi một nút Lighthouse-Besu và khiến chuỗi khối chia làm hai, với các trình xác thực được kết nối với Nethermind hoặc Besu ở cấp độ thực thi trên một nhánh và các trình xác thực được kết nối với Geth trên một nhánh. .

Lưu ý rằng việc kiểm tra khối hiện tạiblockHashlà một yêu cầu được thêm vào hợp nhất, do đó sẽ thiếu hoặc xác thực không chính xác trên một số khách hàng.

Một vấn đề với Geth là khi thực hiện sai tải trọng, nó sẽ trả về lỗi JSON-RPC thay vìINVALID(không hoạt động) và sự cố của Teku (đã được khắc phục nhưng chưa được triển khai vào thời điểm này) là những lỗi đó có thể vượt qua được ở chế độ đồng bộ hóa lạc quan. Do đó, các nút Teku-Geth vẫn chuyển sang chế độ đồng bộ hóa lạc quan khi gặp tải không hợp lệ. Vì bản thân khối đó là hợp lệ, nên các nút Geth được kết nối sẽ lấy dữ liệu từ mạng thay vì engineAPI, do đó, các nút Teku-Geth hiện đang ở trên một ngã ba không hợp lệ. Do các nút Teku vẫn ở phiên bản cũ hơn với nhiều lỗi, các nút Teku-Geth vẫn ở chế độ đồng bộ hóa lạc quan và từ chối đề xuất các khối trong khoảng thời gian chuỗi khối ngừng hoàn thiện. Hiện chúng ta đang ở trong tình huống mà các ứng dụng khách lớp đồng thuận (lighthouse, prysm, nimbus và lodestar) - Geth (khoảng 46%) và ứng dụng khách lớp đồng thuận - Nethermind/Besu (khoảng 19%) nằm trên các nhánh khác nhau, phần còn lại của trình xác thực đang chạy Teku-Geth (khoảng 35%) đang ở chế độ đồng bộ lạc quan.

Sau khi tìm và triển khai các bản sửa lỗi cho các nút Nethermind và Besu, chúng tôi đã có thể đưa chúng trở lại đúng chuỗi. Bản cập nhật cho nút Teku-Geth đã gây ra một sự cố khác liên quan đến quyền truy cập bộ nhớ không hợp lệ, do sự cố trên Geth liên quan đến xác thực thứ tự khối. Lỗ hổng cụ thể này cũng được kích hoạt bởi bộ làm mờ của Marius, tạo ra mộtparentRootlà hợp lệ vàblock_number=1khối. Trước khi Geth thực thi một khối, nó cần xem xét các khối chính của nó để xem liệu chúng có cần được đồng bộ hóa hay không. Một cách để làm điều này là kiểm tra trong bộ đệmparentHashVàparentHashVàblockNumber. Vì Teku thực thi đồng thời tất cả các tải trong tất cả các nhánh, nên bộ đệm không còn chứaparentHash. Do đó, Geth cố gắng chuyển parentHash vàblockNumberTìm khối cha mẹ của nó. Tuy nhiên, cơ sở dữ liệu không có hàm băm của blockNumber này (khối này được xây dựng bởi fuzzer). Geth sẽ suy luận rằng vì nó không có khối chính nên nó cần phải bật đồng bộ hóa. Tuy nhiên, quá trình đồng bộ hóa được kích hoạt theo cách này sẽ cố gắng đồng bộ hóa chuỗi ngắn hơn chuỗi có thẩm quyền, điều này vi phạm một số điều kiện trong Geth, gây ra lỗi quy trình Geth, tắt nút và nút Teku-Geth luôn ở trạng thái không lành mạnh.

Trong quá trình gỡ lỗi sự cố trên, nhóm Geth cũng đã tìm thấy một điều kiện tương tranh trong cơ sở mã được hợp nhất đã gây ra lỗi. Ngoài ra, chúng tôi còn gặp các vấn đề khác - Nimbus có lỗi liên quan đến kết nối lại tầng điều hành, Lodestar đã hạ điểm của các đồng nghiệp từ chối tạo khối.

tiêu đề cấp đầu tiên

FAQ

Hỏi: Testnet này đã chết chưa?

A:KHÔNG. Sau khi chúng tôi triển khai bản sửa lỗi và đồng bộ hóa lại một số nút bị trì trệ, chuỗi cuối cùng đã bắt đầu hoàn thiện lại. Khi quá trình khôi phục chuỗi hoàn tất, nó có thể hoạt động như bình thường. Hiện tại, tỷ lệ tham gia của Kintsugi là khoảng 99%, điều này cho thấy rằng tất cả các máy khách đã được vá lỗi và mạng đang hoạt động tốt. Giao dịch và tương tác hợp đồng thông minh tiếp tục hoạt động như bình thường.

Q: Tại sao chuỗi này không được hoàn thành quá lâu?

A:Mặc dù chúng tôi đã sớm tìm ra nguyên nhân gốc rễ, nhưng chúng tôi muốn giữ cho chuỗi chưa hoàn thiện và để các nhóm khách hàng gỡ lỗi mã của họ. Ngoài ra, chúng tôi muốn thu thập dữ liệu về hiệu suất của khách hàng trong thời gian chưa quyết toán.

Câu hỏi: Trình xác thực trên chuỗi rẽ nhánh có bị cắt giảm không?

A:Sẽ không. Mỗi người xác minh chứa một cơ sở dữ liệu bảo vệ gạch chéo, đảm bảo rằng người xác minh không ký vào các thư có thể bị gạch chéo. Trình xác nhận trên ngã ba "sai" chỉ được coi là không hoạt động trên ngã ba "đúng". Sau khi họ tập hợp lại trên ngã ba "chính xác", cơ sở dữ liệu cắt giảm sẽ ngăn họ ký các thông báo có thể cắt giảm.

Hỏi: Điều này sẽ ảnh hưởng như thế nào đến việc khởi chạy mạng chính? Sẽ có sự chậm trễ mới?

A:Chúng tôi không nghĩ vấn đề này sẽ ảnh hưởng đến kế hoạch ra mắt mainnet. Không có vấn đề nghiêm trọng nào được tìm thấy trong bản thân thông số kỹ thuật. Mục đích của mạng thử nghiệm là tìm lỗi và chúng tôi nghĩ Kintsugi đã làm rất tốt việc tìm ra các trường hợp cạnh trong quá trình triển khai ứng dụng khách. Sự kiện này là một bài kiểm tra căng thẳng tốt cho nhiều tổ hợp khách hàng. Chúng tôi có một danh sách kiểm tra công khai sẽ hướng dẫn chúng tôi khi chúng tôi sẵn sàng hợp nhất trên mạng chính.

Q: Điều này sẽ ảnh hưởng đến kế hoạch kiểm tra như thế nào?

A:Chúng tôi sẽ xem xét việc tạo một số mạng thử nghiệm buộc phải ở trạng thái chưa hoàn thiện. Quá trình thử nghiệm đang diễn ra trên các mạng thử nghiệm chưa hoàn thiện này cho phép chúng tôi kích hoạt nhiều trường hợp cạnh hơn và cải thiện công cụ. Các lỗ hổng được tìm thấy trong sự cố này sẽ được thêm vào dưới dạng các trường hợp thử nghiệm tĩnh để đảm bảo chúng tôi vượt qua các thử nghiệm hồi quy.

Ý nghĩa quan trọng đối với người xác thực, nhà cung cấp cơ sở hạ tầng và nhà phát triển công cụ:

Khoảng thời gian chưa hoàn thiện trên testnet củng cố một số giả định về các yêu cầu phần cứng trong trường hợp xấu nhất. Trong thời gian chưa hoàn thiện, người xác nhận nên mong đợi:

• Tăng tải CPU (đôi khi lên đến 100%) do cần phải đánh giá nhiều quy tắc lựa chọn rẽ nhánh

• Việc sử dụng ổ cứng tăng lên trong thời gian không hoàn thiện vì sẽ không có sự cắt xén

• Sẽ có một sự gia tăng nhẹ trong việc sử dụng RAM

Điều này có nghĩa là bất kỳ công cụ hoặc giám sát bổ sung nào đang chạy trên cùng một máy sẽ dẫn đến tranh chấp tài nguyên. Các công cụ của mạng thử nghiệm Kintsugi (block explorer, vòi, RPC) chạy trên cụm Kubernetes có 3 nút. Cụm này cũng chạy các nút báo hiệu được sử dụng bởi một số công cụ. Do các nút đèn hiệu sử dụng nhiều tài nguyên hơn mức được cung cấp, nên các công cụ của chúng tôi thường chạy một cách xuống cấp do không đủ tài nguyên. Các nhà cung cấp cơ sở hạ tầng nên chạy các lớp thực thi và đồng thuận của họ trên các máy riêng biệt hoặc có các định nghĩa sử dụng tài nguyên nghiêm ngặt.

Hợp nhất có nghĩa là mỗi máy khách lớp đồng thuận cần chạy máy khách lớp thực thi của riêng mình. Máy khách lớp thực thi (trên mạng chính) hiện yêu cầu rất nhiều dung lượng đĩa. Mức sử dụng đĩa của CL cũng có thể tăng đột biến trong các giai đoạn chưa hoàn thiện, điều này có thể dẫn đến sự cố do không đủ dung lượng đĩa. Tất cả các trình xác thực phải đảm bảo rằng chúng có dung lượng đĩa đệm đủ lớn để xử lý loại sự cố này.

Các nhà phát triển công cụ dựa vào tính hữu hạn nên cân nhắc thêm về các giai đoạn không hoàn thiện. Một cách có thể là hiển thịoptimisticThông tin, trong khi chuyển tải thông tin đó trong giao diện người dùng sẽ thay đổi.