Năm câu hỏi về Ethereum: Vấn đề về sự đa dạng của khách hàng đến từ đâu?
Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ethfans)Lưu ý của biên tập viên: Bài viết này đến từ
Những người đam mê Ethereum (ID: ethfans)
Những người đam mê Ethereum (ID: ethfans)
Cuộc họp nhà phát triển cốt lõi lần thứ 90 gần đây đã được dành cho một vấn đề gần như toàn bộ thời gian. Tôi đặc biệt khuyến khích mọi người lắng nghe phiên họp này cho chính họ.
Trong phần này, Alexey đã nêu vấn đề về tình trạng quá tải của nhà phát triển ứng dụng khách. Trong khi tôi nghĩ rằng cuộc thảo luận này là một khởi đầu quan trọng, chúng tôi quá háo hức tìm ra giải pháp để hiểu đầy đủ vấn đề. Điều quan trọng là chúng ta phải dành một chút thời gian để phân tích vấn đề. Khi phân tích nội hàm của câu hỏi, "Five Whys" là một trong những phương pháp đơn giản và hiệu quả nhất.
Không chần chừ thêm nữa, hãy xem câu hỏi đầu tiên là gì.
Geth: 75%
Parity & OpenEthereum: 20%
Nethermind: 1%
tiêu đề phụ
Câu hỏi đầu tiên: Tại sao áp lực lên nhóm phát triển Geth lại lớn như vậy, thậm chí đến mức quá tải?
Thông qua etherscan, chúng ta có thể thấy thống kê dung lượng cài đặt của từng client như sau:
4% còn lại bao gồm một số khách hàng có thị phần dưới 1% và do đó bị bỏ qua.
Điều quan trọng là hơn 51% sức mạnh tính toán tập trung vào ứng dụng khách Geth. Giả sử rằng trong đợt hard fork Berlin sắp tới, Geth gặp lỗi trong quá trình triển khai một trong các EIP (Đề xuất cải tiến Ethereum). Ngay cả khi không có lỗi trong các triển khai khác của ứng dụng khách này, miễn là một khối gặp phải lỗi này, nó sẽ khiến mạng Ethereum bị phân nhánh. Về mặt logic, khối này không hợp lệ và các máy khách khác sẽ coi nó là khối không hợp lệ. Tuy nhiên, hơn 51% các nút khai thác đang chạy ứng dụng khách Geth, vì vậy toàn bộ mạng sẽ được đưa đến sai chuỗi rẽ nhánh.
Do đó, câu trả lời cho câu hỏi đầu tiên là:
Bởi vì các máy khách của mạng Ethereum thiếu sự đa dạng.
Điều đáng nói là việc đa dạng hóa khách hàng sẽ không đột nhiên biến việc phát triển khách hàng trở thành một công việc dễ dàng. Nhưng bản thân sự đa dạng của khách hàng vẫn là một lĩnh vực đáng để khám phá, điều này sẽ giúp chúng tôi tìm ra cách nâng cao hiệu quả phát triển khách hàng đồng thời giảm gánh nặng cho các nhóm phát triển. Không thể phủ nhận rằng chỉ làm việc với nhóm Geth sẽ không giải quyết được vấn đề này.
tiêu đề phụ
Câu hỏi thứ hai: Tại sao mạng Ethereum thiếu sự đa dạng của khách hàng?
Khi mạng chính Ethereum hoạt động, chúng tôi có nhiều khách hàng. Hai trong số những cái chính là Geth và CPPEthereum. Sau đó, Parity xuất hiện và CPPEthereum bị loại bỏ.
Kể từ đó, không có khách hàng nào ngoài Parity giành được thị phần đáng kể. Năm ngoái, Nethermind nổi lên như một ngôi sao đang lên, nhưng hiện chỉ nắm giữ 1% thị trường. Gần đây, thị phần của Parity đã giảm đáng kể do một số thăng trầm và một tương lai ảm đạm cho Parity. Chúng tôi tin rằng, lý tưởng nhất là mạng Ethereum cần có 3 khách hàng trở lên và tỷ lệ khách hàng của mỗi khách hàng không được quá cao và không khách hàng nào có thể chiếm hơn 51% thị phần . Mặc dù lý tưởng nhất là phải đạt được sự đa dạng hóa khách hàng, nhưng chúng tôi đã quen với quyền bá chủ của khách hàng.
Vì vậy, tại sao chúng ta cần nhiều khách hàng?
Ai đó có thể ngay lập tức gợi ý rằng chúng ta nên tìm cách hỗ trợ và giúp đỡ những khách hàng đang bị tụt lại phía sau. Tôi cảnh giác với giải pháp "tháng làm việc thần thoại" này -- đưa nhiều kỹ sư hơn vào một vấn đề khó khăn trong quá trình phát triển phần mềm hiếm khi hiệu quả và tôi không mong đợi điều đó xảy ra.
Thay vào đó, tôi nghĩ nên tập trung vào sự phức tạp.
Lưu ý: Mythical Man-Month, tháng người đàn ông thần thoại, chỉ ra rằng một số lượng lớn người và một khoảng thời gian ngắn không thể rút ngắn tiến độ phát triển phần mềm. Sự đông đúc không giúp ích gì cho việc sản xuất phần mềm, nó tạo ra rắc rối và tạo ra phần mềm tồi tệ hơn. Việc bổ sung nhân lực cho một dự án đang bị chậm tiến độ sẽ chỉ khiến nó càng bị chậm hơn so với kế hoạch.
tiêu đề phụ
Bây giờ, chúng ta đang tiến gần hơn đến gốc rễ của vấn đề.
Hóa ra phần lớn khó khăn đến từ giao thức mạng, bộ công cụ mà phần mềm máy khách ethereum sử dụng để kết nối với nhau và chia sẻ thông tin về chuỗi khối. Các quy tắc mạng của Ethereum (được xác định trong cơ sở mã devp2p) cuối cùng ảnh hưởng và thậm chí xác định thiết kế và yêu cầu của ứng dụng khách Ethereum.
Một số công cụ mạng chỉ định các kiến trúc chưa được tối ưu hóa và thậm chí yêu cầu các máy khách Ethereum chạy các chức năng không cần thiết. Các nhà phát triển khách hàng cần phải làm việc trong những ràng buộc này.
tiêu đề phụ
Câu hỏi 4: Tại sao giao thức liên kết mạng làm tăng độ khó thực hiện của client?
Tôi tin rằng câu trả lời cho câu hỏi này về cơ bản có thể được chia thành hai phần.
quản lý nhà nước
Yêu cầu kết nối mạng tổng thể
Về mặt quản lý trạng thái, một ứng dụng khách Ethereum phải có khả năng đồng bộ hóa trạng thái hoàn chỉnh trên mạng và duy trì một bản sao cục bộ của trạng thái đó. Cả hai đều khó thực hiện. Đồng bộ hóa trạng thái yêu cầu hàng triệu yêu cầu đối với máy khách và máy chủ đọc và xử lý các yêu cầu trạng thái và có thể làm bão hòa I/O của đĩa. Trạng thái mới được đồng bộ hóa cần được duy trì và cắt tỉa để cơ sở dữ liệu có thể thực thi các khối mới đủ nhanh. Từ quan điểm kỹ thuật, đây là một thách thức nghiêm trọng!
GetNodeData là công cụ mạng duy nhất chúng tôi sử dụng để đồng bộ hóa trạng thái, được tối ưu hóa cho định dạng cơ sở dữ liệu trạng thái cụ thể (thường được gọi là "bố cục gốc"). Bố cục cơ sở dữ liệu "phẳng" được phổ biến bởi Turbo Geth có lợi ích hiệu suất tuyệt vời về bảo trì trạng thái, nhưng việc sử dụng bố cục này khiến việc xử lý các yêu cầu GetNodeData trở nên khó khăn hơn.
Xử lý các yêu cầu GetNodeData để truy cập trạng thái được tạo bởi khối gần đây nhất;
Xử lý các yêu cầu truy cập lịch sử dữ liệu trên chuỗi, bao gồm tiêu đề khối, nội dung khối và biên lai.
Câu 5: Tại sao...
giải pháp
Có vẻ như tôi chỉ cần hỏi bốn câu "tại sao" để tìm ra nguyên nhân gốc rễ. Giao thức Ethereum vẫn chưa hoàn thiện. Khi thiết kế giao thức Ethereum, chúng tôi không biết về hầu hết các vấn đề được tìm thấy ngày nay hoặc không phải là vấn đề vào thời điểm đó vì tiểu bang còn nhỏ và lịch sử phát triển ngắn.
tiêu đề phụ
giải pháp
Tôi đã theo dõi câu hỏi này trong năm qua. Tôi nhận ra rằng gốc rễ của nhiều vấn đề trên Ethereum thực sự có thể bắt nguồn từ lớp mạng.
Có lẽ ví dụ rõ ràng nhất là đĩa I/O trong lịch sử đã từng là nút cổ chai đối với máy khách. Nút thắt cổ chai này tồn tại bởi vì các máy khách có xu hướng triển khai cơ sở dữ liệu trạng thái của họ bằng cách sử dụng biểu diễn ngây thơ của cấu trúc cây (Trie). Cách xây dựng cơ sở dữ liệu trạng thái được xác định bởi phần tử mạng GetNodeData.
Để khắc phục điều này, chúng tôi cần đại tu các phần khác nhau của lớp đồng thuận Ethereum cũng như lớp mạng. Hiện tại, công việc bảo trì đã bắt đầu. Rất nhiều công việc đã được thực hiện dưới cái tên "Ethereum không trạng thái" mà Alexey và tôi đã đồng lãnh đạo trong 8 tháng. Một số công việc chúng tôi đã thực hiện ít nhất đã giảm bớt gánh nặng cho nhóm Geth khi họ sử dụng giao thức đồng bộ hóa SNAP mà họ đã phát triển trong nhiều năm. Vẫn có một phần công việc cần được đảm nhận bởi những người tài giỏi, hiểu vấn đề sâu sắc và nghĩ ra các giải pháp khả thi.
Hiện tại, một giao thức DevP2P ETH khổng lồ như vậy vẫn chưa được giải mã hoàn toàn. Chúng tôi có hiểu biết cơ bản về cách chia mạng này thành ba mạng riêng biệt, nhưng chưa có ai trực tiếp thực hiện điều đó.
