1

Q: Quan điểm của bạn về quản trị Ethereum là gì?

Trả lời: Chúng tôi không có vị trí nào vào lúc này. Chúng tôi chịu trách nhiệm đề xuất các thuật toán mới và sẵn lòng trả lời các câu hỏi kỹ thuật về chúng.

2

Hỏi: ProgPoW đến từ đâu?

Đ: IfDefElse là một nhóm nhỏ chuyên phân tích và tối ưu hóa thuật toán PoW. Chúng tôi đã quan sát thấy rằng cộng đồng ETH đã nhiều lần yêu cầu một thuật toán PoW mới, trong đó các máy khai thác ASIC chuyên nghiệp có ít lợi thế hơn so với các cơ sở phần cứng thông thường. Thật đau lòng khi chứng kiến ​​nhiều thuật toán dễ bị tấn công bởi máy khai thác ASIC Mỗi khi một máy khai thác ASIC mới ra mắt, toàn bộ cộng đồng ETH sẽ rơi vào cảnh thất vọng.

Vì vậy, vào một ngày mùa xuân năm 2018, chúng tôi đã có ý tưởng sửa đổi thuật toán Ethash để đạt được hiệu quả khai thác GPU như mong đợi. Sau khi chỉnh sửa thuật toán ban đầu, chúng tôi đưa thuật toán lên diễn đàn công cộng GitHub để phát triển và tinh chỉnh.

H: Ai đã đánh giá ProgPoW?

Trả lời: Trong quá trình thu thập phản hồi về việc sử dụng thuật toán, chúng tôi đã may mắn nhận được email phản hồi từ các kỹ sư Ethereum Foundation, kỹ sư R&D lõi Ethereum, kỹ sư NVIDIA và kỹ sư AMD. Các kỹ sư của NVIDIA và AMD nhìn chung đều nhận xét tích cực về thuật toán.

Điều đáng nói là có hai bản cập nhật và tối ưu hóa thuật toán dựa trên đánh giá của các thành viên cộng đồng mbevand và Schemeykh.

Q: AMD đã phản hồi như thế nào?

Trả lời: Phản hồi của AMD giải quyết hai mối quan tâm chính:

Nếu thuật toán ProgPoW được sử dụng để thay thế thuật toán Ethash PoW, không có cách nào để các nhà sản xuất máy khai thác ASIC nhanh chóng nghiên cứu mã nguồn mở và sản xuất các máy khai thác ASIC chuyên dụng?

Liệu thuật toán ProgPoW có gây khó khăn hơn cho những người khai thác GPU trong việc khai thác Ethereum không?

Một kỹ sư của AMD đã đưa ra câu trả lời khẳng định, về lý thuyết thì có thể xây dựng một cỗ máy khai thác ASIC mới cho ProgPoW nhưng điều này đòi hỏi nhà sản xuất phải có kiến ​​thức nền tảng chuyên sâu về GPU, đặc biệt là công nghệ bộ điều khiển bộ nhớ.

Không chỉ vậy, họ còn bày tỏ lo ngại về kích thước của bộ nhớ đệm (có chia sẻ dữ liệu cục bộ và dữ liệu trên chip AMD).

Họ đã đề cập trong email rằng không có sự khác biệt lớn về hiệu suất giữa AMD và NVIDIA bất kể bộ đệm là 8KB hay 16KB. Nhưng ở mức 32KB và 64KB, có thể có tác động lớn đến kiến ​​trúc của cả hai nhà cung cấp GPU và sẽ có sự không tương thích trên Polaris và Vega.

Dựa trên phản hồi của họ, chúng tôi đặt kích thước của PROGPOW_CACHE_BYTES thành 16KB.

5

Hỏi: NVIDIA đã phản hồi như thế nào?

Đ: Nhìn chung, các kỹ sư của NVIDIA đồng ý với cách tiếp cận của chúng tôi. Họ nói rằng thuật toán lấp đầy khoảng trống giữa các lần truy cập bộ nhớ bằng tính toán, thay vì để GPU ngồi yên như một bộ điều khiển bộ nhớ cao quý.

Mối quan tâm chính của họ là nếu họ thêm quá nhiều tính ngẫu nhiên vào thuật toán, nó sẽ bị giới hạn về mặt tính toán hơn là giới hạn về bộ nhớ. Do đó, các công cụ khai thác ASIC được xây dựng cho các thuật toán bị hạn chế về mặt tính toán có thể đạt được hiệu quả và lợi ích cao hơn.

Dựa trên phản hồi của họ, chúng tôi đã tinh chỉnh PROGPOW_CNT_CACHE và PROGPOW_CNT_MATH để đảm bảo rằng thuật toán vẫn bị giới hạn bộ nhớ trên hầu hết các GPU hiện đại.

Hỏi: Nếu ProgPoW gọi mô-đun trên vòng lặp chính và sử dụng Kiss99() để chọn các lệnh ngẫu nhiên, thì các công cụ khai thác ASIC được thiết kế cho thuật toán này có hiệu quả hơn không?

A: Đây là một quan niệm sai lầm phổ biến khi nhìn vào thuật toán lần đầu tiên. Trên thực tế, việc gọi modulus và Kiss99() trên mạch chính được tính toán bởi CPU để tạo ra một chương trình ngẫu nhiên, sau đó được CPU biên dịch. GPU chịu trách nhiệm thực thi mã được tối ưu hóa đã tìm ra hướng dẫn nào sẽ thực thi và trạng thái hỗn hợp nào sẽ sử dụng.

Như Alexey đã đề cập, ProgPoW tạo mã nguồn sau mỗi 50 khối. Để biết ví dụ về chương trình được tạo, hãy xem: kernel.cu.

Chúng tôi cũng sẽ giải thích thêm trong tiêu chuẩn.

Hỏi: Những người khai thác có cần cài đặt bộ công cụ phát triển phần mềm AMD hoặc NVIDIA để biên dịch mã nguồn được tạo không?

Trả lời: Không cần. Trình điều khiển AMD và NVIDIA bao gồm trình biên dịch OpenCL, DirectX và Vulkan. Đối với CUDA, các tệp hạt nhân nhị phân được phân phối cùng với một bộ công cụ phát triển phần mềm nhỏ.

H: Thuật toán ProgPoW có ưu tiên cho kiến ​​trúc GPU không?

Trả lời: Không, mục đích ban đầu của thuật toán ProgPoW là đảm bảo tính công bằng nhất có thể. Không có sự khác biệt trong quá trình thực thi giữa OpenCL và CUDA và kích thước bộ đệm 16KB chạy trơn tru trên cả hai kiến ​​trúc.

Chúng tôi tránh thực hiện các thao tác 16-bit hoặc 24-bit chỉ trên một kiến ​​trúc, cho dù đó là tệp đăng ký được lập chỉ mục của AMD hay LOP3 của NVIDIA, tất cả các thao tác đều được hỗ trợ tốt qua các thế hệ kiến ​​trúc.

Hiệu suất của GPU sử dụng thuật toán ProgPoW trong khối lượng công việc khai thác cũng sẽ phản ánh hiệu suất chơi trò chơi trung bình của GPU đó.

H: Tại sao sự khác biệt về tốc độ giữa Ethash và ProgPoW lại chậm hơn 2 lần so với dự kiến ​​đối với GPU có VBIOS được sửa đổi nhiều?

Trả lời: ProgPoW đọc gấp đôi bộ nhớ trên mỗi hàm băm so với Ethash, vì vậy tỷ lệ băm dự kiến ​​là 1/2. Tất cả các tốc độ băm mẫu và điều chỉnh mà chúng tôi đã báo cáo trước đây (xem "Kết quả: Tốc độ băm" để biết chi tiết) đã được thực hiện trên GPU chạy ở tần số bình thường. Việc sửa đổi rộng rãi VBIOS để giảm tần số lõi sẽ khiến công cụ khai thác chạy thuật toán bị giới hạn về mặt tính toán thay vì giới hạn về bộ nhớ.

Nếu người dùng có nhu cầu chuyển sang một thuật toán mới thì việc sửa đổi và điều chỉnh VBIOS sẽ cần được thực hiện lại.

H: Bạn có thể giải thích làm thế nào các công cụ khai thác Ethash ASIC hiệu quả gấp đôi so với các công cụ khai thác GPU không?

Thuật toán Ethash chỉ cần thực thi 3 thành phần:

Bộ nhớ băng thông cao (để truy cập DAG)

Dữ liệu FPGA cho thấy tính toán Keccak tiêu thụ điện năng gần như không đáng kể. Chúng tôi ước tính rằng chỉ khoảng 1/2 sức mạnh GPU được sử dụng cho việc truy cập bộ nhớ khi thực hiện thuật toán Ethash. Tuy nhiên, sức mạnh của Keccak và lõi điện toán của máy khai thác Ethash ASIC là không đáng kể và năng lượng của nó chủ yếu được tiêu thụ trong truy cập bộ nhớ, do đó, vẫn còn chỗ để cải thiện gấp đôi hiệu quả khai thác của GPU.

Tóm tắt nhanh về phần cứng khai thác Ethash hiện tại:

Ngoại trừ Titan V, tất cả dữ liệu là từ whattomine.com và asicminervalue.com.

Thế hệ máy khai thác Ethash ASIC đầu tiên, Antminer E3 của Bitmain không có lợi thế về hiệu quả so với các máy khai thác GPU. Điều này là do bộ nhớ DDR3 của nó tiêu thụ nhiều năng lượng hơn bộ nhớ GDDR của các công cụ khai thác GPU.

Theo những gì chúng tôi biết, Innosilicon A10 ETHMaster sắp được phát hành được cho là hiệu quả hơn. Vì Innosilicon sử dụng công nghệ GDDR6 IP trên loạt máy khai thác này, điều này sẽ giúp nó hiệu quả gấp đôi so với GPU khai thác hiệu quả nhất hiện tại là RTX 2070.

Q: HBM thực tế như thế nào?

Trả lời: Đánh giá thuật toán ban đầu của chúng tôi là so sánh điểm chuẩn sử dụng cùng loại bộ nhớ. HBM có mức tiêu thụ điện năng thấp, nhưng nó đắt tiền, vì vậy nó không đủ thực tế. Ví dụ: NVIDIA Titan V với HBM chỉ kém hiệu quả hơn một chút so với A10 ETHMaster, nhưng với mức giá 3.000 đô la, điều đó rõ ràng là không thực tế.

Giá của card AMD Vega với HBM là hợp lý, nhưng không hiểu sao sức mạnh tính toán của nó chỉ có thể đạt 175 KH/s/W. Chúng tôi không chắc điều gì đã hạn chế hiệu quả của Vega, việc tăng kích thước truy cập đã cải thiện đáng kể tình hình (mức sử dụng băng thông tăng từ 61% lên 75% - xem "Kết quả: Hashrate" để biết chi tiết), nhưng mức tiêu thụ năng lượng của card đồ họa Vega vẫn còn quá cao. Chúng tôi đang mong đợi những cải tiến đáng kể về hiệu quả từ card đồ họa AMD Radeon VII Băng thông kép vừa được công bố.

Chúng tôi ước tính rằng sức mạnh của HBM bằng khoảng một nửa so với GDDR6. Nếu HBM được sử dụng để sản xuất các máy khai thác Ethash ASIC đắt tiền, sức mạnh tính toán sẽ vượt quá 1 MH/s/W, tức là gấp khoảng 4 lần hiệu suất của GPU thông thường trên chợ.

Câu hỏi: ProgPoW ASIC có thể hiệu quả đến mức nào?

Trả lời: ProgPoW nhằm mục đích giảm đáng kể mức tăng hiệu quả của các công cụ khai thác ASIC chuyên dụng. Việc thực thi thuật toán cần đáp ứng các thành phần sau:

Keccak có dung lượng nhỏ hơn nên mức tiêu thụ điện năng của nó trên GPU đã không đáng kể. Bằng cách này, lợi thế của máy khai thác ASIC trong việc giảm tiêu thụ điện năng sẽ không còn nữa.

Để thực hiện một chuỗi ngẫu nhiên, công cụ khai thác ProgPoW ASIC cần thực thi một thứ gì đó rất giống với lõi điện toán trên GPU. Tất cả các truy cập thanh ghi SIMD, hoạt động toán học và truy cập bộ đệm yêu cầu thời gian chạy giống như GPU.

Đúng vậy, ProgPoW ASIC ISA có thể được thiết kế chính xác để phù hợp với thuật toán ProgPoW, chẳng hạn như loại bỏ các dấu phẩy động, thêm hợp nhất rõ ràng() và các hoạt động khác. Tuy nhiên, chuyên môn hóa này chỉ mang lại lợi ích cận biên, không phải là thứ tự lợi ích lớn.

Một cách lạc quan, chúng tôi giả định rằng một ProPoW ASIC ISA được thiết kế tốt có thể loại bỏ 1/4 mức tiêu thụ điện năng của lõi máy tính. Vì các lõi GPU hoạt động tích cực hơn nhiều khi thực hiện ProPoW, nên chúng tôi ước tính rằng giao diện bộ nhớ tiêu thụ khoảng 1/3 năng lượng GPU. Sau đó, mức tiêu thụ năng lượng tương đối của máy khai thác Prop PoW ASIC sử dụng GDDR là:

1/3 (bộ nhớ) * 1 + 2/3 (tính toán) * 3/4 ​​= 5/6

lợi thế gấp 1,2 lần

Nếu HBM được sử dụng, mức tiêu thụ năng lượng tương đối của máy khai thác ProgPoW ASIC là:

1/3 (bộ nhớ) * 1/2 + 2/3 (tính toán) * 3/4 ​​= 2/3

lợi thế gấp 1,5 lần

13

H: ProgPoW có thể chạy trên FPGA không?

Trả lời: Đầu tiên, có những vấn đề thực tế khi chạy ProgPoW trên FPGA. Vì chương trình ngẫu nhiên thay đổi sau mỗi 12,5 phút nên các dòng bit mới cần được biên dịch và tải thường xuyên. Các công cụ và phương tiện để thực hiện nhiệm vụ này phần lớn là không tồn tại.

Ngay cả khi bỏ qua vấn đề này, ProgPoW cũng không ánh xạ tốt tới FPGA, vốn hoạt động tốt cho các thuật toán chuyên sâu về tính toán như Keccak hoặc Lyra. Các thuật toán này có thể cải thiện đáng kể hiệu suất và giảm mức tiêu thụ điện năng bằng cách đóng gói nhiều hoạt động vào một chu kỳ xung nhịp duy nhất và chạy nhiều hoạt động đồng thời.

Vòng lặp thuật toán ProgPoW có nhiều lần đọc bộ đệm xen kẽ theo thứ tự, giúp giảm đáng kể các hoạt động có thể được đóng gói vào một chu kỳ đồng hồ đơn lẻ hoặc chạy song song. Theo thuật toán ProgPoW, hoạt động đóng gói của FPGA không chỉ làm giảm hiệu suất của phần cứng khai thác mà còn làm tăng độ dài của kênh thông tin. Độ dài kênh tin nhắn tăng lên cũng là một vấn đề do trạng thái hỗn hợp lớn (16 làn * 32 đăng ký * 4 byte = 2 kilobyte).

Nếu trạng thái hỗn hợp lớn này được nhân rộng theo từng giai đoạn dọc theo mỗi kênh thông tin, thì rất nhiều năng lượng sẽ bị lãng phí. Tất nhiên, chúng ta cũng có thể lưu trữ trạng thái hỗn hợp trong tệp đăng ký, để lõi tính toán của FPGA trông rất giống ASIC hoặc GPU, nhưng trong trường hợp đó, hiệu quả tính toán của FPGA sẽ thấp hơn đáng kể so với hiệu quả tính toán của FPGA. ASIC.

14

Hỏi: Tất cả những câu hỏi và trả lời trên đây có vẻ dài lắm, bạn có thể tóm tắt ngắn gọn được không?

Trả lời: tất nhiên

Hiệu quả tương đối của phần cứng khai thác

Liên kết gốc:

Liên kết gốc:

https://medium.com/@ifdefelse/progpow-faq-6d2dce8b5c8b

Tác giả gốc: IfDefElse Dịch & Soát lỗi: Có một con cá

Bài viết này được dịch và chỉnh sửa bởi Mining Vision, nếu bạn cần in lại, vui lòng ghi rõ nguồn.