V God đã đưa ra đề xuất hard fork đầu tiên HF1 của chuỗi đèn hiệu ETH2.0, giới thiệu cơ chế phạt nút công bằng hơn
Lưu ý của biên tập viên: Bài viết này đến từThông tin Babbitt (ID: bitcoin8btc), bởi Kyle, được xuất bản với sự cho phép.
Lưu ý của biên tập viên: Bài viết này đến từ
Thông tin Babbitt (ID: bitcoin8btc)
Thông tin Babbitt (ID: bitcoin8btc)
, bởi Kyle, được xuất bản với sự cho phép.
"Người sáng lập Ethereum, V God, đã giới thiệu đề xuất nâng cấp của hard fork đầu tiên của Ethereum Beacon Chain (tên dự kiến là "HF1") trên Twitter. V God nói rằng HF1 đã thêm hỗ trợ ứng dụng khách nhẹ và thông số kỹ thuật đơn giản hóa, cải thiện hiệu quả và đã giới thiệu một cơ chế phạt không hoạt động ít trừng phạt hơn.Theo tài liệu, hard fork sẽ cho phép các nhà phát triển thực hiện một số nâng cấp quan trọng đối với chuỗi đèn hiệu được phát hành gần đây và cũng sẽ là một cách để thực hiện các thử nghiệm hữu ích sâu hơn cho các thay đổi. có yêu cầu tài nguyên tối thiểu và có thể chạy trên thiết bị di động. Điều này sẽ cho phép "ví tiền tin cậy tối thiểu" có thể tự xác minh chuỗi khối, thay vì dựa vào các dịch vụ bên ngoài để cung cấp.
HF1 là tên mã dự kiến cho bản nâng cấp hard fork đầu tiên của chuỗi đèn hiệu Ethereum (xem tại đây để biết ý tưởng đặt tên dài hạn cho hard fork này). Các mục tiêu chính của HF1 là:
Thêm hỗ trợ khách hàng nhẹ
Khắc phục một số lỗ hổng trong beacon chain. Những lỗ hổng này đã được phát hiện quá muộn để có thể khắc phục khi quá trình hình thành Beacon Chain bắt đầu.
Cơ chế nâng cấp hard fork của beacon chain được thử nghiệm trong môi trường nâng cấp những thay đổi nhỏ để có thể thực hiện những thay đổi lớn hơn sau này.
Những thay đổi đồng thuận được đề xuất trong HF1 bao gồm:https://github.com/ethereum/eth2.0-specs/pull/2130
Ủy ban đồng bộ hóa
Chúng tôi thêm một "ủy ban đồng bộ hóa" được rút ngẫu nhiên vào chuỗi đèn hiệu. Mục đích của việc này là cho phép các máy khách nhẹ xác định đầu chuỗi với rất ít chi phí hoạt động (tối thiểu khoảng 20 kilobyte mỗi ngày và khoảng 500 byte để xác minh một khối). Điều này sẽ cho phép các khách hàng nhẹ thực sự sử dụng chuỗi đèn hiệu cho các trường hợp sử dụng như thiết bị di động, trình duyệt tích hợp, mở đường cho một hệ sinh thái ví tối thiểu hóa độ tin cậy hơn.
Trong mỗi khoảng thời gian (khoảng 27 giờ), 1024 người xác thực được chọn ngẫu nhiên làm thành viên của ủy ban đồng bộ hóa. Các nút trình xác thực trong ủy ban đồng bộ hóa sẽ cấp chữ ký để chứng thực cho người đứng đầu hiện tại. Những chữ ký này sẽ được phát sóng như một phần của đối tượng LightClientUpdate giúp khách hàng nhẹ tìm thấy đầu này và sẽ được đưa vào chuỗi đèn hiệu để nhận phần thưởng.https://github.com/ethereum/eth2.0-specs/pull/2176
thêm nội dung:
Cải cách sổ sách kế toán (Cấp 1)
Chúng tôi đã thay thế cách tính phần thưởng chứng minh. Thay vì lưu trữ các đối tượng PendingAttestation và xử lý chúng ở cuối, chúng tôi đã chọn thêm một trường bit lưu trữ trạng thái của từng trình xác thực, cho phép tích lũy dữ liệu theo thời gian thực về những người đã tham gia. Các trường bit được sắp xếp theo "thứ tự xáo trộn" để đảm bảo rằng các bản ghi từ các trình xác thực trong cùng một ủy ban xuất hiện cùng nhau. Mục đích của thay đổi này là để đơn giản hóa việc triển khai ứng dụng khách và làm cho việc cập nhật cây Merkle trở nên rẻ hơn.
Tham khảo cụ thể:
Cải cách sổ sách kế toán (Cấp 2)https://github.com/ethereum/eth2.0-specs/issues/2098
Chúng tôi thực hiện các thay đổi đối với bộ trình xác thực và việc ghi sổ phạt chỉ xảy ra sau mỗi 64 kỷ nguyên chứ không phải từng kỷ nguyên. Mục đích của việc này là để giảm đáng kể sự phức tạp của việc xử lý "chuyển đổi khoảng thời gian trống" - ví dụ: có một chuỗi với mức độ tham gia rất thấp trong đó hai khối liên tiếp được phân tách bằng một nghìn vị trí chỉ có một khoảng thời gian trống giữa chúng. Để xử lý các chuỗi như vậy, khách hàng hiện tại cần xử phạt các trình xác thực vì không hoạt động bằng cách tính toán lại số dư của từng trình xác thực sau mỗi kỷ nguyên; trong đề xuất mới, họ chỉ cần thực hiện việc đó sau mỗi 64 kỷ nguyên.
Ngoài ra, chúng tôi đã thực hiện hai thay đổi đối với cách hoạt động của hình phạt không hoạt động:https://github.com/ethereum/eth2.0-specs/pull/2192
https://github.com/ethereum/eth2.0-specs/pull/2194
Hình phạt không hoạt động sẽ trở thành bậc hai cho mỗi trình xác thực. Nghĩa là, nếu có một hình phạt không hoạt động trong đó một trình xác thực hoàn toàn ngoại tuyến sẽ mất khoảng 10% số dư, thì một trình xác thực đã trực tuyến 90% thời gian trong khoảng thời gian này sẽ chỉ mất khoảng 0,1% số dư của nó (so với đến ~1%). Điều này cố gắng tập trung các hình phạt vào các nút thực sự hoạt động sai và ít hơn vào các nút trung thực đang ngoại tuyến do sự cố kết nối mạng.
INACTIVITY_PENALTY_QUOTIENT: reduced from 2**26 (= 67,108,864) to 3 * 2**24 (= 50,331,648)
PROPORTIONAL_SLASHING_MULTIPLIER: increased from 1 to 2
MIN_SLASHING_PENALTY_QUOTIENT: reduced from 2**7 (= 128) to 2**6 (= 64)
Thảo luận thêm có thể được tìm thấy ở đây:
Các hình phạt không hoạt động của trình xác thực sẽ dần dần chậm lại thay vì dừng lại sau khi được xác định. Điều này đảm bảo rằng khi đạt đến trạng thái cuối cùng, các nút ngoại tuyến sẽ tiếp tục mất số dư trong một khoảng thời gian, đảm bảo rằng tỷ lệ phần trăm thời gian trình xác thực trực tuyến cao hơn đáng kể so với 2/3, thay vì chỉ cao hơn một chút so với ngưỡng đó.
Tham khảo cụ thể:
Một điều đáng mừng là bằng cách giảm bớt hình phạt của trình xác nhận, chúng tôi có thể hơi (mặc dù không hoàn toàn) lạc lõng. Chúng tôi sẽ thay đổi các hằng số:
Các thay đổi về lựa chọn rẽ nhánh được triển khai (gần như) cùng lúc với HF1https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf
(khối, khe) cặp (cặp) lựa chọn ngã ba
Hiện tại, nếu không có khối nào được xuất bản trong vị trí gần đây nhất, thì nó được coi là khối mới nhất trong chuỗi mà trình chứng minh đang hỗ trợ cho mục đích chứng minh LMD GHOST trong vị trí đó. Ví dụ: trong sơ đồ dưới đây, bằng chứng về TRỐNG được tính là bằng chứng về A:https://github.com/ethereum/eth2.0-specs/pull/2197
Tuy nhiên, điều này mở ra cơ hội cho các cuộc tấn công 34%. Giả sử m trình xác thực được gán cho mỗi vị trí, trong đó kẻ tấn công độc hại kiểm soát 0,34*m. Kẻ tấn công cũng có quyền xuất bản khối B cho vị trí n+1. Cuộc tấn công diễn ra như sau: Kẻ tấn công không công bố B, cũng như không có bất kỳ bằng chứng nào về việc đó. Tất cả những người chứng thực trung thực sẽ bỏ phiếu cho tuyên bố rằng họ đã nhìn thấy khối A ở vị trí n và không có gì ở vị trí n+1 và số phiếu này hiện được coi là phiếu bầu cho A. Trong ô n + 2, một người đề xuất trung thực sẽ xây dựng một khối C trên đỉnh của A. Tại thời điểm này, người đề xuất ác ý sẽ thông báo B và bằng chứng của nó về B cho ô n + 1 và n + 2. Ngã ba trên có 0,68*m trình xác thực hỗ trợ nó, nhưng ngã ba trên cùng chỉ có 0,66*m hỗ trợ, vì vậy ngã ba dưới sẽ thắng.
Cuộc tấn công này được mô tả chi tiết hơn trong Phần 3.1 của bài báo:
Giải pháp được đề xuất là thay đổi cách thức hoạt động của lựa chọn ngã ba để nó hoạt động trên một cây các cặp (khối, khe) thay vì một cây các khối. Vì vậy, trong biểu đồ trên, phiếu bầu trung thực trong vị trí n+1 sẽ được tính là phiếu bầu cho (BLANK,n+1), vì vậy chúng sẽ được tính chính xác là ủng hộ fork ở trên, vì vậy mức hỗ trợ mà fork ở trên nhận được là 1,32*m, do đó đánh bại cuộc tấn công.
