BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Trang chủ
AI AI
Tin nhanh
Bài viết
Sự kiện
BlockBeats Pro
Thêm
Thông tin tài chính
Chuyên đề
Hệ sinh thái chuỗi khối
Mục nhập
Podcast
Data
OPRR
Partnered With:

HF1, đề xuất hard fork đầu tiên của chuỗi Beacon ETH2.0, đã làm gì?

Đọc bài viết này mất 16 phút
Cơ chế trừng phạt nút công bằng hơn
Tiêu đề gốc: "Buterin phát hành đề xuất hard fork HF1 đầu tiên 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"
Nguồn gốc: Babbitt


“Người sáng lập Ethereum V God đã giới thiệu đĩa cứng đầu tiên của chuỗi đèn hiệu Ethereum trên TwitterFork (tên dự kiến là "HF1"). Vitalik tuyên bố rằng HF1 bổ sung hỗ trợ khách hàng nhẹ, đơn giản hóa các thông số kỹ thuật và cải thiện để nâng cao hiệu quả cũng như đưa ra cơ chế phạt ít mang tính trừng phạt hơn khi không hoạt động. Theo 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 beacon chain được phát hành gần đây và cũng sẽ hữu ích để thực hiện những thay đổi sâu hơn trong tương lai. . Điều này sẽ cho phép "giảm thiểu độ tin cậyví"Có thể tự xác minh chuỗi khối thay vì dựa vào các nhà cung cấp dịch vụ bên ngoài."


HF1 là đèn hiệu Ethereum Tên mã dự kiến cho đợt nâng cấp hard fork đầu tiên của chuỗi (xem tại đây để biết ý tưởng đặt tên dài hạn cho hard fork này) . 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 khởi tạo Beacon Chain được khởi chạy.


  • Thử nghiệm cơ chế nâng cấp hard fork của beacon chain trong môi trường nâng cấp thay đổi nhỏ hơn để tạo điều kiện cho những thay đổi lớn hơn trong tương lai.


Những thay đổi đồng thuận được đề xuất trong HF1 bao gồm:


Ủ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 báo hiệu. Mục đích của việc này là để cho phép các máy khách hạng nhẹ xác định đầu chuỗi với rất ít chi phí (ít nhất chỉ khoảng 20 kilobyte mỗi ngày và chỉ khoảng 500 byte để xác minh một khối). Điều này sẽ cho phép các client hạng nhẹ thực sự sử dụng beacon chain trong các trường hợp sử dụng như thiết bị di động, trình duyệt tích hợp, v.v., mở đường cho một hệ sinh thái ví giảm thiểu độ tin cậy hơn.


Trong mỗi khoảng thời gian (khoảng 27 giờ), 1024 người xác nhận đượ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 xác thực trong ủy ban đồng bộ hóa sẽ cấp chữ ký để chứng minh cho người đứng đầu hiện tại. Những chữ ký này sẽ được phát đi như một phần của đối tượng LightClientUpdate, giúp các khách hàng ánh sáng tìm thấy phần đầu này và sẽ được đưa vào chuỗi đèn hiệu để được thưởng.


Nội dung khác: https://github.com/ethereum/eth3.0-specs/pull/2130">https://github github.com/ethereum/eth3.0-specs/pull/2130


Cải cách kế toán (Cấp 1)


Chúng tôi đã thay thế cách tính phần thưởng của người chứng minh. Thay vì lưu trữ các đối tượng Đang chờ chứng thực 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ự ngẫu nhiên" để đảm bảo rằng các bản ghi từ những người xác nhận 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à giúp việc cập nhật cây Merkle rẻ hơn.


Tham khảo cụ thể: https:// github.com/ethereum/eth3.0-specs/pull/2176


Cải cách kế toán (cấp độ thứ hai)


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 tính toán hình phạt chỉ xảy ra sau mỗi 64 kỷ nguyên, thay vì mỗi kỷ nguyên riêng lẻ. Mục đích của việc này là để giảm đáng kể sự phức tạp khi xử lý "chuyển đổi giai đoạn trống" - ví dụ: có một chuỗi có mức độ tham gia rất thấp trong đó hai khối liên tiếp cách nhau một nghìn vị trí và chỉ có một khoảng trống giữa chúng. Để xử lý chuỗi như vậy, hiện tại, khách hàng cần tính toán lại số dư của từng người xác thực một lần trong mỗi kỷ nguyên, từ đó phạt những người xác nhận không hoạt động; với đề xuất mới, họ chỉ cần thực hiện việc này sau mỗi 64 kỷ nguyên.


Ngoài ra, chúng tôi đã thực hiện hai thay đổi về cách thức áp dụng hình phạt không hoạt động:


  • Hình phạt không hoạt động sẽ trở thành bậc hai đối với mỗi trình xác thực. Nghĩa là, nếu có hình phạt không hoạt động và trình xác thực hoàn toàn ngoại tuyến trong khoảng thời gian này sẽ mất ~ 10% số dư của nó, thì trình xác thực trực tuyến 90% thời gian trong khoảng thời gian này giờ đây sẽ chỉ mất ~ 0,1% số dư của nó (so với ~ 1%). Điều này cố gắng tập trung hình phạt vào các nút thực sự hoạt động sai và ít hình phạt hơn đối với các nút trung thực đang ngoại tuyến do sự cố kết nối mạng.  


Bạn có thể tìm thêm thảo luận tại đây: https://github.com/ethereum/eth3.0-specs/issues/2098


  • Hình phạt không hoạt động của trình xác nhận 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 cân bằng trong một thời gian, đảm bảo rằng tỷ lệ phần trăm người xác thực thời gian trực tuyến cao hơn đáng kể so với 2/3, thay vì chỉ cao hơn ngưỡng đó một chút.  


Tham khảo cụ thể: https://github.com/ethereum/eth3.0-specs/pull/2192


https://github.com/ethereum/eth3. 0-specs/pull/2194


Thật đáng ăn mừng rằng bằng cách giảm mức phạt của trình xác thực, chúng tôi có thể hơi (mặc dù không hoàn toàn) ra khỏi các loại gỗ . Chúng ta sẽ thực hiện các thay đổi đối với các hằng số:


  • INACTIVITY_PENALTY_QUOTIENT: giảm từ 2**26 (= 67,108,864) xuống 3 * 2**24 (= 50,331,648)


  • PROPORTIONAL_SLASHING_MULTIPLIER : tăng từ 1 lên 2


  • MIN_SLASHING_PENALTY_QUOTIENT: giảm từ 2**7 (= 128) xuống 2**6 (= 64 )


Các thay đổi lựa chọn nhánh được triển khai tại (gần) cùng thời điểm với HF1


(Khối, vị trí) Lựa chọn nhánh của (cặp)


Hiện tại, nếu không có khối nào được phát hành trong vị trí gần đây nhất, nghĩa là đã hết thời gian trong vị trí đó. nhằm mục đích chứng minh LMD GHOST, người chứng minh được coi là đang hỗ trợ khối mới nhất trong chuỗi. Ví dụ, trong hình bên dưới, phép chứng minh trên BLANK được tính là phép chứng minh trên A:


V神发布ETh3.0信标链首个硬分叉提案HF1,引入更公平的节点惩罚机制


Tuy nhiên, điều này mở ra cơ hội cho một cuộc tấn công 34%. Giả sử rằng 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 tiến hành như sau: kẻ tấn công không công bố B cũng như bất kỳ bằng chứng nào của nó. Tất cả những người chứng minh trung thực sẽ bỏ phiếu cho tuyên bố rằng họ đã nhìn thấy khối A ở ô thứ n và không thấy gì ở ô thứ n+1, và hiện tại số phiếu này được coi là phiếu bầu cho A. Ở vị trí n + 2, người đề xuất trung thực sẽ xây khối C lên trên A. Lúc này, người đề xuất ác ý sẽ xuất bản B và bằng chứng về B của nó lên các vị trí n + 1 và n + 2. Ngã ba phía trên có trình xác nhận 0,68*m hỗ trợ nó, nhưng ngã ba trên chỉ có hỗ trợ 0,66*m, vì vậy ngã ba phía dưới sẽ thắng.


Cuộc tấn công này được mô tả chi tiết hơn trong Chương 3.1 của bài báo: https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf


Giải pháp được đề xuất là thay đổi cách lựa chọn nhánh hoạt động để nó hoạt động trên cây gồm các cặp (khối, khe) thay vì cây khối. Vì vậy, trong sơ đồ trên, các phiếu bầu trung thực ở 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à do đó 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.


Nội dung khác: https://github.com/ethereum/eth3.0-specs/pull/2197">https://github.com github.com/ethereum/eth3.0-specs/pull/2197


Sửa lỗi tấn công cân bằng lựa chọn fork


Có sự "tấn công cân bằng" trong lựa chọn fork, với A 2% Kẻ tấn công trình xác thực sẽ xuất bản một số lượng nhỏ bằng chứng vào đúng thời điểm trước khi thời gian kết thúc, thuyết phục hơn 49% mạng lưới rằng một khối A nhất định đã thắng và hơn 49% mạng tin rằng khối B đã thắng. Nếu họ tính thời gian phát sóng chính xác, mỗi nhóm trình xác thực sẽ thấy thông báo dành cho họ đúng lúc, nhưng sẽ không có thời gian để phát lại thông báo đến một nhóm trình xác thực khác trước khi thời gian kết thúc. Nếu môi trường mạng là tối ưu cho kẻ tấn công thì chúng có thể được lặp lại vô thời hạn.


Giải pháp được đề xuất là làm cho hướng hỗ trợ của tất cả những người xác thực trở nên mang tính quyết định bằng cách trao quyền cho người đề xuất vị trí tiếp theo để có tác động tạm thời nhưng đáng kể đến sự lựa chọn phân nhánh ... Mặt đất dịch chuyển sang bên này hay bên kia, do đó "phá vỡ tính đối xứng".


Liên kết gốc



Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

举报 Báo lỗi/Báo cáo
Chọn thư viện
Thêm mới thư viện
Hủy
Hoàn thành
Thêm mới thư viện
Chỉ mình tôi có thể nhìn thấy
Công khai
Lưu
Báo lỗi/Báo cáo
Gửi