Kế hoạch an ninh mạng của ETC và PirlGuard
Last updated
Last updated
Bảo mật là điều tối quan trọng đối với Ethereum Classic. Để đối phó với các cuộc tấn công mạng gần đây, chúng tôi đang phát triển một kế hoạch chiến lược và mạnh mẽ để đưa ETC về phía trước. Là người quản lý của một chuỗi khối công cộng, chúng tôi quyết tâm bảo vệ tính toàn vẹn của hệ sinh thái. Chúng tôi đang đầu tư thêm nguồn lực, nhân lực và tài chính để tăng cường bảo mật, củng cố mạng lưới và đảm bảo một tương lai tươi sáng cho ETC.
Kế hoạch an ninh mạng bao gồm (1) các hành động ngay lập tức mà chúng tôi đang thực hiện để ngăn chặn các cuộc tấn công; và (2) một số thay đổi dài hạn, hiện đang được phát triển, có thể được triển khai trong vòng 3–6 tháng.
Chúng tôi đang thực hiện một số bước ngay lập tức đề phòng các cuộc tấn công. Điều này cung cấp các lớp bảo mật mới cho mạng. Bao gồm các:
Khai thác phòng thủ thông qua hợp tác với các thợ đào và nhóm khai thác để duy trì tốc độ băm ổn định hơn và tăng tốc độ băm khi cần thiết.
Giám sát mạng nâng cao để xác định sự bất thường và đột biến trong tỷ lệ hash dư thừa và giá trên các pool khai thác.
Phối hợp chặt chẽ với các sàn giao dịch về địa chỉ trong danh sách trắng và thiết lập thời gian xác nhận an toàn.
Triển khai hệ thống trọng tài cuối cùng “Permapoint” do ETC Core Team phát triển để tích cực ngăn chặn việc tổ chức lại chuỗi trong khi duy trì sự đồng thuận giữa các nút.
Có nhiều loại đề xuất khác nhau hiện đang được phát triển để sửa chữa lâu dài, tất cả đều yêu cầu sự đồng thuận của cộng đồng để tiếp tục:
Tăng khả năng chống tấn công 51%. Điều này có thể đạt được với các tính năng như check-pointing hoặc PirlGuard. Những điều này có thể được thực hiện thông qua một đợt hard fork trong khoảng 3 tháng sau khi thông số kỹ thuật hoàn tất.
Thay đổi thuật toán khai thác bằng chứng công việc. Hai lựa chọn thay thế đang được xem xét là Keccak-256 hoặc RandomX. Những điều này có thể được thực hiện thông qua một đợt hard fork trong khoảng 6 tháng, miễn là quá trình thử nghiệm được hoàn thành thành công.
Hỗ trợ thực hiện những thay đổi như vậy, thông qua MINERVOTE chẳng hạn.
Giới thiệu hệ thống kho bạc, nếu đạt được sự đồng thuận của cộng đồng.
Cộng đồng của Ethereum Classic đang xem xét một số lựa chọn để tăng khả năng chống lại các cuộc tấn công 51%, có thể được thực hiện trong khoảng 3 tháng. Mặc dù chỉ những điều này sẽ không ngăn chặn được các cuộc tấn công, nhưng chúng sẽ là một phần của một loạt các nâng cấp trên ETC. Một lựa chọn là PIRLGUARD, được phát triển và đề xuất bởi cộng đồng Pirl (Nguồn: PIRLGUARD — Giải pháp sáng tạo chống lại các cuộc tấn công 51% ). ECIP-1092 nói rằng thay vì tự động đồng bộ hóa với bất kỳ nhánh chuỗi nào được khai thác trước ngoại tuyến, giao thức mới sẽ yêu cầu ngang hàng đề xuất chuỗi dài hơn và nặng hơn để khai thác một số khối phạt. Số lượng khối phạt phụ thuộc vào số lượng khối ban đầu sẽ được hoàn nguyên nếu chuỗi được tổ chức lại và đồng bộ hóa với đề xuất tổ chức lại. Do đó, chi phí của cuộc tấn công 51% sẽ tăng lên đáng kể vì kẻ tấn công sẽ không thể xuất bản chi nhánh riêng của họ mà không tăng gấp đôi công việc của họ bằng cách thêm các khối hình phạt. Điều này sẽ bảo vệ mạng khỏi hoàn nguyên tất cả các giao dịch từ các nhánh được khai thác công khai.
Một đề xuất khác là tăng cường chuỗi với checkpointing và dấu thời gian (Nguồn: Bảo mật sổ cái bằng chứng công việc thông qua điểm kiểm tra). Đề xuất này sẽ sử dụng một nhóm các bên bên ngoài điều hành một cách an toàn dịch vụ hỗ trợ đảm bảo các thuộc tính của sổ cái và có thể được tin cậy vào những thời điểm khi sức mạnh băm đã thấp. Tuy nhiên, vẫn chưa có đề xuất cụ thể nào cho mạng Ethereum Classic. Bất kỳ đề xuất nào sẽ phải được đánh giá cẩn thận về tính khả thi của nó với ETC.
Động lực chính để thay đổi thuật toán là thoát ra khỏi bóng của mạng Ethereum được cung cấp bởi bằng chứng công việc của Dagger Hashimoto, còn được gọi là Ethash. Điều này có thể được thực hiện trong vòng 6 tháng, tùy thuộc vào kết quả thử nghiệm. Là một chuỗi thiểu số liên quan đến tổng tỷ lệ băm bằng cách sử dụng cùng một thuật toán khai thác như mạng Ethereum, Ethereum Classic không chỉ dễ bị tấn công 51%, mà các cuộc tấn công này có thể thực hiện do tỷ lệ băm có sẵn có thể được thuê trên nhiều nền tảng khác nhau.
Việc chuyển sang một thuật toán khai thác duy nhất có thể đưa Ethereum Classic trở thành người dẫn đầu trong loại bằng chứng công việc của riêng nó.
Cho đến nay, cộng đồng Ethereum Classic đã thảo luận về một số thuật toán, hai trong số đó đầy hứa hẹn:
SHA3, hoặc cụ thể là Keccak256 của Ethereum (ECIP-1049)
RandomX, một bằng chứng công việc cho các CPU đa năng (ECIP-1093)
Nếu cộng đồng quyết định ủng hộ thay đổi thuật toán khai thác, chúng tôi có thể bắt đầu làm việc theo một trong hai lựa chọn sau: thay đổi sang thuật toán khai thác thân thiện với GPU và ASIC như Keccak256; hoặc thuật toán thân thiện với CPU, kháng ASIC giống như RandomX được phát triển bởi cộng đồng Monero.
Chuyển sang RandomX, hiện đang được Monero sử dụng, có thể không giải quyết được hoàn toàn các vấn đề mà chúng tôi hiện đang gặp phải. Có tiềm năng thoát ra khỏi cái bóng của mạng Ethereum và bước vào cái bóng của mạng Monero như một chuỗi thiểu số khác.
Việc sử dụng Keccak256 từ họ SHA3 sẽ đặt Ethereum Classic ở vị trí độc nhất là người dẫn đầu tiềm năng liên quan đến tỷ lệ băm của thuật toán khai thác riêng của nó. Điều này sẽ cho phép ETC trở nên độc lập hơn với chuỗi chị em dựa trên Ethash của nó, giảm đáng kể nguy cơ bị tấn công do thuật toán khai thác được chia sẻ.
Tiến trình tiềm năng cho các đề xuất là:
● Giai đoạn 0 : (Tháng 8/2020) Đồng thuận sơ bộ.
o Tìm kiếm sự đồng thuận của cộng đồng để tiến tới với các đề xuất trên. Các cuộc gọi cộng đồng công khai được lên kế hoạch vào ngày 20 tháng 8 và ngày 28 tháng 8 năm 2020, để tạo thành một sự đồng thuận sơ bộ. (Xem: (Các) cuộc gọi ETC Core Devs 2020 Q3: Hardfork).
o Ngoài ra, chúng tôi khuyến khích các thợ đào báo hiệu ủng hộ bất kỳ đề xuất nào như SHA3 hoặc RandomX càng sớm càng tốt (So sánh: ECIP-1076 ).
● Giai đoạn 1 : (Tháng 9/2020) Triển khai.
o Các thay đổi được cộng đồng chấp thuận sẽ được triển khai ngay lập tức trong các ứng dụng máy khách Core-Geth và Hyperledger Besu.
● Giai đoạn 2 : (Tháng 10/2020) Testnets công khai cho các biện pháp chống tấn công (tức là các checkpoints). Kiểm tra và Lặp lại một thuật toán khai thác mới.
Cùng với việc triển khai, thử nghiệm riêng tư, devnet tạm thời và testnet bán công khai sẽ được chuẩn bị cho thuật toán khai thác mới.
● Giai đoạn 3 : (11/2020) Kích hoạt Mainnet của các biện pháp kháng tấn công, tức là các trạm kiểm soát.
● Giai đoạn 4 : (12/2020) Testnet công khai cho thuật toán khai thác mới.
o Sau khi triển khai và thử nghiệm thành công, hãy khởi chạy kích hoạt testnet ở một số khối thích hợp.
● Giai đoạn 5 : (01/2021) Kích hoạt Mainnet của thuật toán khai thác mới.
o Sau khi thực hiện và thử nghiệm thành công, hãy khởi chạy kích hoạt mainnet ở một số khối khởi chạy thích hợp.
Các đề xuất sau đây mô tả các quy trình hữu ích trong việc tìm kiếm sự đồng thuận cho một cái gì đó liên quan như thay đổi thuật toán khai thác.
(Trạng thái: Bản nháp) ECIP 1022: Phiên bản chung Bỏ phiếu Bits cho sự đồng thuận mềm và Hard Fork (Generalized Version Bits Voting for Consensus Soft and Hard Forks) — “ECIP sau đây cố gắng đưa các phương pháp hay nhất về cách Bitcoin xử lý với hard fork đồng thuận (BIP-9 và BIP-135) vào Ethereum Classic. Thay vì viết mã cứng một số khối như chúng ta hiện đang làm, mỗi khối được khai thác tạo ra sự hỗ trợ của hardfork đồng thuận mới. Chỉ khi một phần đủ lớn của mạng hỗ trợ nó, hardfork mới được “khóa” và sẽ được kích hoạt. “
(Trạng thái: Bản nháp) ECIP 1076: Quy trình thay đổi thuật toán khai thác — “ Tài liệu này không phù hợp với bất kỳ thuật toán khai thác nào. Mục đích duy nhất của nó là chỉ định một quy trình làm thế nào để xác định và chọn một thuật toán khai thác cho Ethereum Classic một cách công khai. ”
Các đề xuất sau có tiềm năng giải quyết các cuộc tấn công 51% và tăng khả năng phục hồi của Ethereum Classic trước các mối đe dọa trong tương lai.
(Trạng thái: Bản nháp) ECIP 1043: Đã sửa lỗi giới hạn DAG — “Mục đích của ECIP này là đặt giới hạn về kích thước tối đa của DAG và không còn tăng nó theo lịch trình kỷ nguyên.”
(Trạng thái: Bản nháp) ECIP 1049: Thay đổi Thuật toán Bằng chứng Công việc ETC thành Keccak256 — “Đề xuất thay thế thuật toán Bằng chứng Công việc Ethereum Classic hiện tại bằng Keccak-256.”
(Tình trạng: Bản nháp) ECIP 1092: Giải pháp chống tấn công 51%: PirlGuard & Callisto
(Trạng thái: Bản nháp) ECIP-1093: Thay đổi Thuật toán Bằng chứng Công việc ETC thành RandomX — “Đề xuất thay thế thuật toán Bằng chứng Công việc Ethereum Classic hiện tại bằng RandomX.”
Các đề xuất sau đây đã được thảo luận trong cộng đồng nhưng vẫn thiếu một tài liệu thực tế mô tả đặc điểm kỹ thuật.
● (Trạng thái: Không xác định) “Hệ thống kho bạc Ethereum Classic”
● (Trạng thái: Không xác định) “Proof-of-Work Checkpointing”
Các đề xuất sau đây phù hợp với cuộc thảo luận hiện tại nhưng đã bị cộng đồng từ chối trong quá khứ.
● (Trạng thái: Bị từ chối) ECIP 1051: Hệ thống kho bạc của Ethereum Clasic— “Phần sau mô tả khả năng triển khai cơ chế tài trợ phát triển.”
● (Trạng thái: Bị từ chối) ECIP 1070: ProgPoW, Bằng chứng công việc có lập trình, dành cho Ethereum Classic — “ProgPoW là thuật toán bằng chứng công việc được thiết kế để thu hẹp khoảng cách hiệu quả có sẵn cho các ASIC chuyên dụng. Nó sử dụng hầu hết tất cả các bộ phận của phần cứng hàng hóa (GPU) và được điều chỉnh trước cho phần cứng phổ biến nhất được sử dụng trong mạng Ethereum.”