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%

简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Thông tin khô khan | Thử nghiệm cốt lõi Ethereum 2.0

Đọc bài viết này mất 28 phút

Báo cáo thử nghiệm ứng dụng khách Ethereum Prysm hoàn toàn cốt lõi

Tiêu đề gốc: " Tôi đã thử nghiệm Ethereum 2.0, nền tảng lõi cứng 》

Nguồn gốc: Wang Zeshu, Cộng đồng HashQuark

Prysm là một triển khai xuất sắc của ETH2.0 và hiện là triển khai được sử dụng phổ biến nhất trên mạng thử nghiệm Huân chương. Prysm áp dụng kiến trúc của Beacon Chain Node + Validator Node. Cái trước chịu trách nhiệm đồng bộ hóa dữ liệu khối và cái sau chịu trách nhiệm ký các khối và chứng kiến. Vì Nút Trình xác thực có thể tải nhiều trình xác thực cùng một lúc nên chúng tôi đã đặc biệt sắp xếp thử nghiệm này để hiểu rõ về mặt định tính và định lượng về số lượng trình xác thực mà nó có thể tải và các bước triển khai trình xác thực có liên quan.

Kết luận thử nghiệm

Chúng tôi đã sao chép mạng thử nghiệm Huy chương , đã xây dựng Chuỗi báo hiệu ETH2.0 của riêng HashQuark, tiến hành hai vòng thử nghiệm, tổng cộng 14 trường hợp thử nghiệm và chạy hàng trăm nghìn Trình xác thực. Việc triển khai Prsym rất tốt, đối với người dùng bình thường có số lượng ETH nhỏ (hàng chục đến hàng trăm Trình xác thực) và muốn tham gia Ethereum Stake, máy chủ đám mây 8G 4 nhân có thể chạy Beacon Chain Node và Trình xác thực một cách trơn tru. , những vấn đề kỹ thuật gặp phải trong quá trình vận hành không thể được giải quyết bởi những người dùng thông thường không có kỹ thuật.

Đối với các nhóm khai thác PoS chuyên dụng chạy hàng chục nghìn Trình xác thực, cần có cấu hình cao hơn để đảm bảo tỷ lệ chặn cực cao. Tốc độ sản xuất khối sẽ giảm khi số lượng Người xác nhận tăng lên.

Tiếp theo, chúng tôi sẽ tiến hành vòng thử nghiệm tiếp theo trên mạng thử nghiệm công cộng Huân chương để gần hơn với môi trường mạng chính. Hiện tại, chúng tôi đã chạy gần 3.000 thử nghiệm trên Huy chương. Trình xác thực, chiếm 5% toàn bộ mạng.

Môi trường thử nghiệm

Chúng tôi sử dụng geth để xây dựng mạng ETH1.0 riêng tư và thử nghiệm công khai Giống như Rinkeby hoặc Goerli, thuật toán chứng minh quyền lực “bè phái” được sử dụng vì nó yêu cầu ít tài nguyên hơn PoW. Prysm sử dụng phiên bản phát hành mới nhất tại thời điểm thử nghiệm.

Để triển khai máy chủ đám mây dùng trong các thử nghiệm sau, chúng tôi đã chọn mẫu N đa năng và nền tảng CPU là Intel/Broadwell. Hệ thống sử dụng Ubuntu 18.04.2 LTS. Phiên bản geth ổn định 1.9.19 và phiên bản Prysm là v1.0.0-alpha.24.

Thử nghiệm sơ bộ giai đoạn đầu

Giải pháp thử nghiệm

Trước tiên, chúng tôi tiến hành một thử nghiệm đơn giản về áp lực lên tài nguyên máy chủ với số lượng trình xác thực khác nhau để có được hiểu biết cơ bản.

Sử dụng hai nút ETH1.0 cơ bản nhất + hai nút Chuỗi Beacon ETH2.0 + hai kiến trúc Nút xác thực để xây dựng mạng riêng làm kế hoạch dùng thử ban đầu. Một ngày khi mạng chạy ổn định là thời gian quan sát.

Các trường hợp thử nghiệm

Bảng sau đây cung cấp thông tin tổng quan về quá trình thử nghiệm của chúng tôi:

Bảng 1 ;

Các chỉ số kiểm tra

Trong quá trình thử nghiệm xử lý chúng tôi Các chỉ số như CPU, bộ nhớ, IO ổ đĩa, IO băng thông mạng, v.v. của mỗi máy chủ phiên bản đều được thu thập.

Quy trình thử nghiệm

Trong thử nghiệm 1, 2 lõi Bộ nhớ của 4G Beacon Chain Node tăng dần theo từng giai đoạn, sau khi chạy khoảng 6 tiếng, mức sử dụng bộ nhớ đạt 100% khiến tiến trình gặp lỗi hết bộ nhớ và buộc phải dừng lại, đồng thời CPU mức sử dụng cũng tăng dần. Như được hiển thị bên dưới:

Hình 1

Hình 2

Sau đó, chúng tôi đã nâng cấp cấu hình Beacon Chain Node lên 8G 4 nhân.

Trong ví dụ 2-5, số lượng trình xác thực đã tăng lên 1k-10k để quan sát CPU máy chủ, bộ nhớ, IO đĩa, băng thông và dữ liệu chỉ báo khác, và không có áp lực. , không có ngoại lệ.

Sau đó, chúng tôi đã triển khai các nút ETH2.0 ở các khu vực khác nhau để quan sát xem liệu điều kiện kết nối mạng ở các khu vực khác nhau có tác động lớn hơn đến các chỉ số khác nhau hay không. không đáng kể.

Tóm tắt thử nghiệm

Dựa trên tình hình thử nghiệm mạng riêng, Beacon Chain Node khuyến nghị 4 lõi Cấu hình 8G, Validator node Cấu hình 4G 2 nhân là đủ nhưng khi import file key thì CPU 1 nhân sẽ bị chiếm dụng và tỉ lệ lấp đầy CPU là 100% (như hình bên dưới). bên cạnh, cấu hình 4C6G được khuyến nghị.

Hình 3

Thử nghiệm so sánh giai đoạn thứ hai

Kế hoạch thử nghiệm

Giai đoạn đầu tiên chủ yếu kiểm tra áp lực của số lượng người xác nhận khác nhau đối với tài nguyên máy chủ. Ngoài ra, việc sản xuất và chứng kiến khối của người xác thực cũng rất quan trọng đối với người xác nhận. . Với mục đích này, chúng tôi đã tiến hành một thử nghiệm so sánh. Trong cùng một mạng, số lượng trình xác nhận khác nhau được triển khai ở các khu vực khác nhau để thử nghiệm so sánh.

Các chỉ số kiểm tra

Trong quá trình kiểm tra, chúng tôi sẽ thu thập CPU, các chỉ số bao gồm bộ nhớ, IO đĩa, IO băng thông mạng, số khối nên được tạo, số khối được tạo thực sự, số khối nên được chứng kiến, số khối được chứng kiến thực sự, v.v.

Các trường hợp thử nghiệm

Sau đây là các trường hợp thử nghiệm của chúng tôi: ;

Bảng 2

Mạng ETH1.0 bao gồm ba máy chủ đám mây 4G 2 lõi, hai máy chủ đặt tại Hồng Kông và một máy chủ ở Sao Paulo. Thời gian khối được đặt thành 15 giây.

Chúng tôi đã triển khai Nút chuỗi Beacon và Nút xác thực ở sáu khu vực: Hồng Kông, Singapore, Los Angeles, Frankfurt, Sao Paulo và Luân Đôn. Nút chuỗi Beacon và Nút xác thực ở mỗi khu vực được kết nối thông qua mạng nội bộ. Cấu hình và số lượng validator tương ứng như trên.

Phiên bản 1 và phiên bản 2 đều có trình xác nhận 1k. Sự khác biệt nằm ở cấu hình của Nút xác thực, được sử dụng để so sánh tác động của số lượng trình xác thực với các cấu hình khác nhau trên các chỉ số.

Các trường hợp 3,4,5,6 tăng số lượng người xác thực. Vì thực tế chúng tôi khó có thể đặt hơn 10 nghìn trình xác thực trên một máy nên chúng tôi đã dừng số thử nghiệm ở mức 20 nghìn.

Nút chuỗi Beacon ở mỗi khu vực được kết nối với các nút khác.

Lựa chọn tham số mạng thử nghiệm

Lần đầu tiên chúng tôi triển khai nó trên mạng ETH1.0. hợp đồng tiền gửi, sau khi tạo ra số lượng khóa xác thực cần thiết, đã gửi các giao dịch tiền gửi theo đợt. Các tham số sau đã được sửa đổi khi Prysm được khởi động:

MinGenesisActiveValidatorCount được đặt thành 8192, điều này đạt yêu cầu vì thử nghiệm của chúng tôi bao gồm 40 nghìn trình xác thực;

Eth1FollowDistance được đặt thành 20, có nghĩa là hợp đồng tiền gửi trên mạng ETH1.0 sẽ được mạng ETH2.0 giám sát sau 5 phút;

SecondsPerETH1Block được đặt thành 15, phù hợp với từng ETH1 Mạng .0 Cài đặt thời gian khối nhất quán;

MinGenesisTime được đặt thành 1599811200, có nghĩa là nó sẽ bắt đầu sớm nhất vào 2020-09-11T16:00:00+08:00.

Trên thực tế, vì chúng tôi đã gửi trước tất cả các giao dịch gửi tiền để đáp ứng số lượng người xác thực tối thiểu được đặt tại thời điểm bắt đầu sớm nhất nên toàn bộ mạng ETH2.0 đã được vào năm 1599811207 (2020 -09-11T16:00:07+08:00) bắt đầu.

Thống kê dữ liệu và kết quả kiểm tra

Chúng tôi đã triển khai thêm Nút chuỗi Beacon để kết nối với mạng riêng ETH2.0 nhằm truy vấn dữ liệu. Thêm tham số --slots-per-archive-point=1 để lưu trữ liên tục dữ liệu của từng khối nhằm tăng tốc độ truy vấn. Việc thêm tham số --rpc-max-page-size=1000 cho phép chúng tôi truy vấn nhiều dữ liệu hơn mỗi lần, từ đó giảm số lượng yêu cầu và tăng tốc độ tổng thể.

Chúng tôi đã chọn khoảng thời gian mạng tương đối ổn định, từ kỷ nguyên 75 (khoảng 2020-09-12 00:00:00 +0800) đến 1200 lấy mẫu kỷ nguyên (2020 -09-17 00:00:00 +0800), lấy dữ liệu sản xuất khối và dữ liệu chứng kiến của người xác nhận trong các trường hợp khác nhau trong khoảng thời gian này và phân tích dữ liệu đó, đồng thời nhận được kết quả sau:

Tất cả trình xác thực Tất cả các khối đều được tạo thành công và không có khối nào bị thiếu;

Tình hình chứng kiến của trình xác nhận ở các khu vực khác nhau hơi khác nhau:

Bảng 3

Ở đây chúng tôi xác định tỷ lệ chứng kiến đối với được đưa vào trong một khoảng thời gian. Số lượng nhân chứng được chia cho số lượng nhân chứng được chỉ định cho nó. Không khó để nhận thấy rằng, nhìn chung, khi số lượng người xác nhận tăng lên thì tỷ lệ nhân chứng sẽ giảm đi. Nhưng ở Ví dụ 3, dù chỉ có 2k validator nhưng tỷ lệ nhân chứng lại thấp hơn tỷ lệ nhân chứng là 6k, thậm chí 10k.

Để khám phá lý do dẫn đến tỷ lệ nhân chứng tổng thể bất thường trong Ví dụ 3, chúng tôi đếm tỷ lệ nhân chứng của những người xác nhận trong từng trường hợp và phân tích nó để xem liệu đó là do lỗi của các trình xác nhận riêng lẻ. Vấn đề đã làm giảm tỷ lệ tổng thể.

Chúng tôi chia từng tỷ lệ trình xác thực theo phạm vi và thu được dữ liệu sau:

Bảng 4

Vì số lượng trình xác nhận trong mỗi phiên bản là khác nhau, nên nó được chuyển đổi thành một tỷ lệ Nó sẽ trực quan hơn:

Bảng 5

Có thể thấy tỷ lệ nhân chứng của hầu hết các validator ở instance 3 là không cao, điều đó cũng có nghĩa là ở instance 3 chắc chắn có vấn đề.

Vì lý do này, chúng tôi đã kiểm tra nhật ký của phiên bản 3 và nhận thấy rằng kết nối giữa Beacon Chain Node với các nút khác và ETH1.0 không ổn định. Chúng tôi suy đoán rằng điều này đã gây ra tỷ lệ nhân chứng giảm xuống.

Áp lực máy chủ

Trong vòng thử nghiệm này, chúng tôi quan sát thấy bảng sau Chỉ báo hiệu suất dữ liệu:

- Beacon Chain Node

Trong trường hợp 1-5, mức sử dụng CPU của Beacon Chain Node là từ 5%-10% và của trường hợp 6 Mức sử dụng CPU của Beacon Chain Node là khoảng 12%. Bộ nhớ cho thấy mức tăng ổn định, từ 12% đến 17% và không có sự khác biệt đáng kể về IO và băng thông của đĩa.

- Nút xác thực

Khi số lượng trình xác nhận tăng lên, các mục khác nhau của Nút xác thực Các chỉ số ngày càng tăng đều đặn, có thể thấy IO đĩa và băng thông về cơ bản tỷ lệ thuận với số lượng người xác thực.

Ngoài ra, để tạo tệp khóa xác minh, chúng tôi sử dụng công cụ hậu lệnh python được đề xuất (https://github.com/ethereum/eth2.0-deposit-cli), công cụ này tương đối kém hiệu quả trong việc tạo khóa. Cao, máy đa lõi chỉ chiếm 1 lõi và mất khoảng 2,5 giờ để tạo ra 2000 cặp khóa. Mặt khác, việc nhập cặp khóa của Nút xác thực cũng được thực hiện trên một lõi duy nhất và thời gian nhập 2000 cặp khóa là khoảng 40 phút.

Tóm tắt kiểm tra

Đã vượt qua vòng kiểm tra này, Chúng tôi đã quan sát thấy trong mạng riêng rằng việc tăng số lượng trình xác thực sẽ ảnh hưởng đến tốc độ sản xuất khối của tất cả các trình xác thực trên nút. Đối với một trình xác thực duy nhất, trong trường hợp tốt nhất và xấu nhất, số lượng trình xác thực trung bình ít hơn khoảng 10 nhân chứng mỗi ngày khối. Không có sự khác biệt nào được tìm thấy trong thử nghiệm của chúng tôi về việc tạo khối. So với CPU và băng thông, việc sử dụng bộ nhớ và IO đĩa tăng rõ ràng hơn khi số lượng trình xác nhận tăng lên.

Các kế hoạch và các bước thử nghiệm tiếp theo cần được tối ưu hóa

Trong vòng thử nghiệm này, các khía cạnh sau được tính đến để biết thêm Thời gian chuẩn bị:

Tạo cặp khóa trình xác thực

Triển khai hợp đồng ký gửi

Cặp khóa nhập nút trình xác thực

Trong kế hoạch tiếp theo, chúng tôi dự định tối ưu hóa các bước trên để nâng cao hiệu quả thử nghiệm.

Ngoài ra, trong kế hoạch thử nghiệm tiếp theo, có tính đến sự ổn định giữa các mạng ở các khu vực khác nhau và tác động của nó đối với các chỉ số của trình xác thực, các điểm sau có thể được xem xét Cải thiện :

Thêm nhiều phiên bản thử nghiệm trong cùng một khu vực để so sánh xem có sự khác biệt do khu vực gây ra hay không;

Triển khai nhiều nút ETH1.0 để Beacon Chain Node có thể kết nối suôn sẻ với ETH1. .0 để giảm tác động;

Thêm các thử nghiệm so sánh riêng biệt trong cùng một khu vực, tăng số lượng trình xác thực, biến kiểm soát và chỉ cần so sánh tác động của số lượng trình xác thực.

Về mặt dữ liệu thống kê, hãy cân nhắc bổ sung thêm nhiều chiều hơn, chẳng hạn như xem xét khoảng cách giữa các nhân chứng được đưa vào, v.v. Bạn có thể tham khảo bài viết này về hiệu quả của nhân chứng ( https://www.attestant.io/posts/defining-attestation-effectness/) bài viết.

Tóm tắt các vấn đề kiểm tra

Khối lượng dữ liệu GRPC vượt quá kích thước mặc định

Khi số lượng trình xác thực tăng lên gần 4k, Nút xác thực sẽ báo cáo kích thước thông báo lỗi 5350532 (5M) mà grpc thu được vượt quá giá trị tối đa là 4194304 (4M).

Hình 4

Giải pháp: Sử dụng tham số --grpc-max-msg-size để tăng kích thước tin nhắn được grpc cho phép một cách thích hợp khi khởi động Nút xác thực.

Không thể đồng bộ hóa nút chuỗi đèn hiệu

Trong vòng thử nghiệm đầu tiên, Khi chỉ có hai Nút chuỗi Beacon trong mạng, hai nút này rất dễ không thể đồng bộ hóa các khối và không nút nào coi bên kia là ngang hàng phù hợp. Như được hiển thị bên dưới:

Hình 5

Giải pháp: Hiện tại chúng tôi đang sử dụng phương pháp đồng bộ lại dữ liệu của các nút rõ ràng để giải quyết vấn đề. Trong quá trình thử nghiệm, chúng tôi nhận thấy rằng khi số lượng nút Chuỗi Beacon tăng lên thì sự cố này không còn xảy ra nữa.

Số tiền gửi bị báo cáo sai là không đủ

Nếu phép tính sau xảy ra, activeEpoch quá lớn hoặc số tiền gửi quá lớn. Nếu không đủ nhưng thực tế là đủ, điều đó có nghĩa là có vấn đề với việc triển khai Prysm. Vui lòng tham khảo vấn đề này(https://security.feishu.cn ), sự cố này đã được khắc phục trong phiên bản mới nhất của báo cáo này.