Thỏa hiệp trên ECIP-1049: Giữ gìn sự đồng thuận trong khi áp dụng Keccak256 thông qua Soft Fork.
Thỏa hiệp không phải là thất bại. Đó là việc quyết định rằng người khác cũng có quyền được hạnh phúc với kết quả cuối cùng giống bạn.
Một số điều đáng chú ý đã xảy ra vào tuần trước trong cuộc gọi thảo luận trực tuyến của cộng đồng ETC. Trước hết cộng đồng đã chọn từ chối ProgPoW. Điều này rất quan trọng vì rõ ràng thuật toán khủng khiếp này là một sự tấn công trực tiếp vào mạng lưới bằng cách buộc nó vào mã lệnh không đạt tiêu chuẩn được xây dựng bởi đội hình CSW . Quyết định tuyệt vời!
Tuy nhiên, chúng tôi không thể đạt được sự đồng thuận của cộng đồng rõ ràng cho ECIP-1049. Tại sao lại thế này? Những người chống lại nó đã đưa ra trường hợp của họ, và những mối quan tâm chính mà chúng tôi nghe thấy là:
- Keccak256 là một thuật toán bằng chứng công việc rất tốt, nhưng rủi ro của việc chuyển đổi là quá cao và có khả năng rủi ro khi thực hiện trực tiếp trên mạng.
- Nếu chúng ta thiết kế ETC từ đầu, sẽ hợp lý khi áp dụng Keccak256, nhưng thật không công bằng khi chuyển thuật toán Proof of Work trực tiếp trên mạng.
Trước tiên, hãy để tôi nói, tôi không đồng ý với cả hai quan điểm này. Nếu cho đủ thời gian và với sự đơn giản của thuật toán Keccak256, tôi tin rằng nó sẽ khá dễ dàng để chuyển đổi và có sức mạnh băm (hashrate) đa số. ETC tạo ra hơn 33 triệu đô la (khoảng 100.000 đô la một ngày) mỗi năm bằng tiền mới và điều này là quá đủ để hỗ trợ một hệ sinh thái khai thác lành mạnh.
Nhưng tôi cũng thừa nhận, đây là đầu cơ và thực sự có những rủi ro tiềm tàng trong việc chuyển đổi. Chúng thấp, nhưng vẫn có khả năng hệ sinh thái khai thác có thể không được chuẩn bị và khiến mạng dễ bị tổn thương tại thời điểm chuyển đổi. Điều này mang lại cho tôi một thỏa hiệp:
ECIP-1049 sẽ được sửa đổi để thấy rằng:
Thay vì thay thế hoàn toàn Ethash bằng Keccak256, thay vào đó mạng lưới có thể chấp nhận cả hai giá trị băm là hợp lệ để chứng minh bằng chứng công việc. Một khối có thể được niêm phong bằng cả 2 thuật toán Ethash HOẶC Keccak256.
Một hệ thống kép về bằng chứng công việc, làm thế nào có thể đạt được điều này mà không cần thêm nhiều sự phức tạp vào hệ thống?
Vâng, nó thực sự khá đơn giản. Trước tiên, bạn cần hiểu Ethash thực sự là gì — đó là Keccak256, nhưng cần nhiều bộ nhớ để kháng ASIC.
Một phần của yêu cầu đối với các công cụ đòi hỏi nhiều bộ nhớ chính là thứ được gọi là “mixHash”, một chuỗi 256 bit có thể được sử dụng để tạo DAG. Bởi vì Keccak256 không cần dag (DAG chỉ tồn tại cho mục đích kháng ASIC ASIC) chúng tôi nhận được chuỗi 256 bit bổ sung này rất hữu ích, bạn thực sự có thể lấp đầy nó bằng bất cứ điều gì bạn muốn. Vì vậy, đây giống như các miếng đệm và bu lông:
Nếu một người khai thác xem 0x0000là 4 ký tự đầu tiên của mixHash - thì nó sẽ kiểm tra xem khối có được niêm phong bằng Keccak256 hay không, nếu có, thì khối đó hợp lệ. Nếu nó không nhìn thấy 0x0000nó sẽ kiểm tra xem nó có được niêm phong bằng Ethash không, nếu có, khối này hợp lệ.
if blockheader.mixHash [0: 4] == '0x0000':
validateKeccak256PoW () other:
validateEthashPow ()Điều này cho phép cả hai bên đạt được chính xác những gì họ muốn:
- Những người ủng hộ Keccak, có thể gửi công việc lên blockchain được coi là hợp lệ. Điều này có nghĩa là các công ty khai thác chuyên dụng có thể tạo ra chip và ASIC cho mạng lưới và bảo vệ chống lại các nhóm khai thác Ethash lừa đảo tiềm năng, giống như một nhóm đã tấn công 51% lên ETC nhiều lần vào tháng 1 năm 2019.
- Những người ủng hộ việc ở lại với Ethash bây giờ biết rằng, nếu chúng tôi kích hoạt ECIP1049 và chúng tôi không có bất kỳ công cụ khai thác Keccak nào trên mạng, đó không phải là vấn đề vì mọi người vẫn có thể tiếp tục hoạt động như bình thường.
- Nếu ECIP1049 được kích hoạt, không cần công cụ mới nào được tạo ra, vì hiện tại hai phương thức PoW được coi là hợp lệ so với chỉ một. Mọi người đều đồng ý rằng cả hai phương pháp PoW này đều có khả năng chống va chạm và có thể hoạt động để niêm phong khối.
Trên thực tế, chúng tôi tin rằng, giải pháp này đủ điều kiện là một ngã ba mềm, bởi vì Ethash là một hỗn hợp của Keccak256 cộng với rất nhiều thứ khác. Bằng cách loại bỏ sự lộn xộn, chúng tôi chỉ chấp nhận một tập hợp con của những gì chúng tôi từng chấp nhận. Tuy nhiên, nó không phải là một Soft Fork thực sự, bởi vì máy khách vẫn cần được cập nhật. Tôi rất quan tâm để lắng nghe những gì mà cộng đồng tin vào.
Câu hỏi và phê bình tiềm năng:
Nhưng điều này quá phức tạp, chúng ta cần dành nhiều năm để phân tích điều này để tìm ra nó!
Nó thực sự không quá phức tạp từ góc độ phần mềm. Bởi vì chúng tôi không thay đổi bất kỳ cấu trúc khối nào (hiện tại sẽ rất phức tạp). Chỉ cần thêm một kiểm tra vào trường MixHash, chúng tôi biết khi nào nên thực hiện Ethash và khi nào thực hiện Keccak256.
Vì Keccak256 là một tập hợp con của Ethash, chúng tôi chỉ đơn giản là loại bỏ sự lộn xộn mà Ethash đã thêm vào.
Tại sao bạn chọn 0x0000 làm mã kích hoạt? Có đúng kích cỡ không
Đây là một câu hỏi hay. Vì vậy, một lợi thế của việc áp dụng Keccak256 hiện là các nhà sản xuất khối và các nhà khai thác có thể có 256 bit để thêm dữ liệu vào mỗi khối. Điều này có thể rất hữu ích, vì nó cho phép những thứ như bỏ phiếu, khai thác onchain, phân tích, thông điệp nhóm — khả năng là vô tận!
Bằng cách lấy một số bit đó phải được điền với 0x0000, chúng tôi giảm được điều đó. Tuy nhiên, chúng ta cần phải cân bằng với thực tế rằng một trong số 65536 khối Ethash được khai thác sẽ có 4 ký tự đầu tiên của hỗn hợp (16 chữ số hex có thể mũ 4 = 65,536). Vì vậy, với phương pháp này, trung bình cứ 1 trong số 65.536 khối Ethash hợp lệ sẽ bị từ chối. Tôi tin rằng đây là một con số chấp nhận được.
Điều này sẽ ảnh hưởng đến flyclient như thế nào?
Cuối cùng, với tình hình hiện tại, không có flyclient vì nó quá đắt để tính toán Ethash. Để xây dựng một flyclient thực sự, chúng ta cần mỗi khối là Keccak256, vì vậy thật dễ dàng để xác thực nó mà không cần phải xem xét DAG hoặc Epoch hoặc các mảnh khác trong Ethash.
Nếu cộng đồng thực sự quan tâm đến flyclient, nó sẽ bỏ Ethash hoàn toàn, nhưng có nhiều thành viên nói rằng họ thích ý tưởng về flyclient, nhưng không sẵn sàng thực hiện những thay đổi mà các kỹ sư đang xây dựng nó yêu cầu. Điều này có nghĩa là họ không thực sự quan tâm đến Flyclient hoặc có thể không hiểu đầy đủ về nó.
Cuối cùng, FlyClient sẽ phải đọc một vài bit đầu tiên của hỗn hợp và nếu nó có mã kích hoạt, nó sẽ kích hoạt, nếu không, nó sẽ phải xử lý Ethash theo cách riêng của nó.
Tuy nhiên, tôi tin rằng ngày càng nhiều người khai thác sẽ bắt đầu sử dụng các công cụ khai thác Keccak256, điều đó có nghĩa là flyclient có thể đưa ra các giả định về mô hình bằng chứng công việc.
Tôi hy vọng rằng điều này giải quyết các mối quan tâm của cộng đồng và chúng ta có thể tiến lên với việc bảo vệ mạng lưới và áp dụng mật mã tốt nhất có thể.
Theo Alexander Tsankov
— — — — — — — — — — — — — — — — — — — — — -
Tham gia thảo luận và cập nhật tin tức mới nhất trên các kênh chính thức của chúng tôi:
- Facebook: facebook.com/EthereumClassicVietnam/
- Telegram: t.me/ETCVietnam
- Twitter: twitter.com/etcvietnam
- Medium: medium.com/@ETCVietnam
- Youtube: youtube.com/channel/UCXfEBzpKKy1pwl7KGCzS7ow
