Trong vài tháng qua, chúng tôi đã xây dựng một nguyên mẫu , tổ chức một cuộc thi hackathon , thuê một nhóm hoàn toàn mới , chỉ định RPCh là một dịch vụ để cung cấp cho ví (và người dùng) cổng blockchain riêng tư đầu tiên của họ và xây dựng một phiên bản sandbox để thể hiện điều đó tất cả đều khả thi.

Nếu điều đó vẫn chưa đủ, bây giờ là thách thức thực sự: một phiên bản RPCh thực sự hoạt động, xử lý các giao dịch tiền điện tử của người dùng thực qua mạng HOPR thực.

Chúng tôi đã quyết định phiên bản này sẽ là một bản alpha. Không phải tất cả các tính năng sẽ được triển khai và những khách hàng cũng như người dùng đầu tiên sẽ có những kỳ vọng thực tế về độ tin cậy, lỗi và các lỗi khác đi kèm với bất kỳ bản phát hành mã sớm nào. Nhưng tất nhiên nó vẫn cần phải hoạt động.

Để sẵn sàng cho bản alpha, nhóm đã mở rộng lại. Michal, nhà phát triển front-end có kinh nghiệm, đã được nhóm liên lạc của HOPR mang đến trên cơ sở chia sẻ và Martins mới được tuyển dụng để giúp đáp ứng các yêu cầu về devops ngày càng tăng của RPCh.

vào cỏ dại

Một trong những thay đổi lớn trong việc phát triển RPCh alpha là sự tập trung ngày càng nhiều vào các chi tiết và thử nghiệm. Thật thú vị khi nói về quyền riêng tư trên lý thuyết và chơi với các nguyên mẫu, nhưng một sản phẩm thực sự cần phải tồn tại và phát triển trong thế giới thực. Thế giới của cung, cầu và lợi nhuận mỏng như dao cạo.

RPCh cần xử lý các cuộc gọi trực tiếp do người dùng thực thực hiện về hoạt động kinh doanh DeFi của họ. Điều này tạo ra hai vấn đề về quy mô:

• RPCh (và mạng HOPR bên dưới nó) có thể xử lý lưu lượng truy cập trực tiếp không?
• RPCh có thể xử lý các cuộc gọi RPC lớn không?

RPCh được xây dựng dựa trên HOPR, vì vậy nó cần sử dụng định dạng mà HOPR có thể xử lý. Các cuộc gọi cần phải được chuyển đổi để chúng có thể được gửi qua mixnet và tập hợp lại ở đầu bên kia.

Về cơ bản, điều này có nghĩa là chia từng cuộc gọi thành các phần có kích thước vừa phải.

Hay đúng hơn là các phân đoạn RPCh có kích thước 400 byte, vì đó là những gì còn lại từ gói HOPR, sau khi bạn cho phép dữ liệu bổ sung mà RPCh cần thêm vào mỗi gói để hoạt động.

Bây giờ hầu hết các cuộc gọi RPC đều nhỏ. Một vài ngọn gói. Và trong nguyên mẫu ban đầu và cuộc thi hackathon, chúng tôi chủ yếu thử nghiệm với các giao dịch truyền thống, rất đơn giản. Nhưng một số cuộc gọi RPC là rất lớn! Thử nghiệm cho thấy rằng một giao dịch Cowswap đơn lẻ có thể yêu cầu tới 50 phân đoạn RPCh, mỗi phân đoạn thực hiện một lộ trình khác nhau thông qua mạng hỗn hợp HOPR.

Và nếu một cái bị thiếu, toàn bộ cuộc gọi sẽ thất bại.

Một điều khác cần nhớ là ví thực hiện cuộc gọi ngay cả bên ngoài giao dịch. Chỉ cần kích hoạt ví của bạn trong trình duyệt, bạn sẽ thấy các cuộc gọi thường xuyên để kiểm tra số dư, kiểm tra số khối hiện tại, v.v. Đây là những khoản nhỏ, nhưng nếu nhiều người dùng có ví hoạt động cùng một lúc thì lưu lượng truy cập sẽ nhanh chóng tăng lên. Bạn có thể tự mình xem bằng cách sử dụng DERP và chỉ cần để ví của bạn mở.

Giờ đây, các đối tác ban đầu của chúng tôi là những chiếc ví nhỏ hơn tập trung vào quyền riêng tư — chúng tôi đang đàm phán với Metamask, nhưng đó là một số cách giải quyết — nhưng nó vẫn có rất nhiều người dùng. Hàng trăm nghìn cuộc gọi mỗi ngày cho tất cả người dùng của họ.

Vì vậy, ngay cả ở dạng alpha, RPCh cần xử lý nhiều lệnh gọi cùng lúc, một số lệnh gọi lớn bất thường.

Nhưng điều đó quá mơ hồ để có ích. Vì vậy, chúng tôi cần thực sự đi sâu vào dịch vụ thực tế mà RPCh sẽ cung cấp. Không chỉ là “gửi một loạt các lệnh gọi RPC qua HOPR” mà còn là “Gọi cái gì?”, “Có bao nhiêu?”, “Chúng lớn cỡ nào?”, “Có bao nhiêu cuộc gọi cùng một lúc?” Không chỉ là phỏng đoán, con số chính xác.

Vì vậy, tôi giao nhiệm vụ cho Diego và Luis thu thập dữ liệu. Họ đã dành hàng giờ chạy ví từ các dự án đối tác của chúng tôi, ghi lại những cuộc gọi đã được thực hiện và kích thước chính xác của chúng tính bằng byte.

Đó là một công việc buồn tẻ, không nói dối, nhưng điều cần thiết là phải biết chính xác tải trọng RPCh alpha sẽ cần xử lý.

Nó sẽ làm việc?

Có vẻ lạ khi đã tiến xa đến mức này mà không làm việc ở mức độ chi tiết này. Nếu nó không thể hoạt động thì sao?

Nhưng đây thực sự là một phần quan trọng trong quá trình phát triển sản phẩm, đặc biệt là khi làm việc trên một thứ hoàn toàn mới.

“Nó sẽ hoạt động chứ?” có nghĩa là những thứ khác nhau ở các giai đoạn khác nhau.

Trở lại vào tháng 9, khi tôi đang viết mã nguyên mẫu RPCh đầu tiên ở Tây Ban Nha, "Nó có hoạt động không?" chỉ có nghĩa là "Điều này thậm chí có thể thực hiện được từ xa không?"

Trong Hackathon, "Liệu nó có hoạt động không?" có nghĩa là "Chúng ta có thể tích hợp cái này vào ví thật không?"

Và khi chúng ta ngày càng tiến gần hơn đến ngày ra mắt, ý nghĩa của việc RPCh hoạt động ngày càng trở nên cụ thể hơn.

Nó không đủ để có thể gửi các giao dịch một cách riêng tư. Dịch vụ phải đáng tin cậy. Nó không thể giới thiệu độ trễ không thể chấp nhận được. Nó phải có khả năng xử lý thông lượng dự kiến ​​của các ví đối tác của chúng tôi. UX phải mượt mà. Nó phải sử dụng mạng HOPR thực, không phải phiên bản hộp cát lý thuyết mà chúng tôi tạo ra cục bộ.

Và thực tế của hoạt động kinh doanh bắt đầu. Bởi vì chúng ta đừng đùa giỡn — ví tiền quan tâm đến quyền riêng tư, nhưng không phải bằng bất cứ giá nào. Nó cần phải dễ sử dụng, dễ tích hợp.

Và tiền nói chuyện. Lý tưởng nhất là RPCh phải rẻ hơn so với đối thủ cạnh tranh hoặc giới thiệu tiết kiệm chi phí ở nơi khác.

Chúng tôi tin rằng chúng tôi có một thiết kế đạt được tất cả những điều này, nhưng chúng tôi vẫn phải đưa nó vượt qua các bước của nó.

Thử nghiệm!

RPCh alpha hiện đã đạt đến giai đoạn thử nghiệm và toàn bộ nhóm đang làm việc suốt ngày đêm để đảm bảo chúng tôi có thể cung cấp dịch vụ trơn tru và đáng tin cậy cho các đối tác ví đầu tiên của mình. Không phải mọi thứ đều diễn ra suôn sẻ - nếu nó xảy ra thì đã không phải là phát triển phần mềm! Nhưng tôi vui mừng thông báo rằng các lỗi đã được tìm thấy và tiêu diệt và mọi thứ dường như đang đi đúng hướng.

HOPR làm việc theo nhóm

Hành trình đến alpha đánh dấu một cột mốc mở rộng quy mô khác: chính nhóm HOPR. Tôi đã làm việc với HOPR kể từ khi thành lập, ngay cả trước khi Hiệp hội HOPR được thành lập. Lúc đầu, sự rung cảm là khởi nghiệp thuần túy: mọi người tham gia vào bất cứ nơi nào họ có chuyên môn. Khi dự án phát triển, cấu trúc đã thay đổi, nhưng vẫn trôi chảy. Chúng tôi đã có những đội chuyên dụng nhưng có rất nhiều sự chồng chéo.

Nhưng việc bổ sung nhóm RPCh đã thay đổi mọi thứ một lần nữa. Bây giờ chúng tôi có ba nhóm với các mục tiêu, thời hạn và yêu cầu khác nhau. Cấu trúc đã được củng cố và giờ đây có thể mất hàng tuần mà không cần tương tác với một số thành viên trong nhóm ngoại trừ cuộc gọi chung tay của chúng tôi.

Điều này đã đưa ra những thách thức mới về phối hợp và sắp xếp thứ tự ưu tiên, đặc biệt là khi mỗi nhóm trải rộng trên toàn cầu. Làm việc hướng tới RPCh alpha là một bài kiểm tra thực sự về tinh thần đồng đội trong toàn bộ HOPR và tôi tự hào nói rằng chúng tôi đã vượt qua thử thách.

Nhóm RPCh chịu trách nhiệm xây dựng RPCh, nhưng toàn bộ nhóm HOPR sẽ góp phần vào thành công của nó: nhóm cốt lõi đã xây dựng giao thức HOPR mà RPCh chạy trên đó và nhóm comm chịu trách nhiệm thông báo về RPCh và sắp xếp hợp lý cộng đồng để chạy các nút chuyển tiếp HOPR và cung cấp một mạng ổn định.

Con đường đến với RPCh alpha sắp kết thúc. Đó là một thách thức, nhưng vô cùng bổ ích. Và tất nhiên alpha chỉ là khởi đầu. Sẽ có nhiều tính năng hơn, nhiều cải tiến hơn cũng như nhiều ví và người dùng hơn để hỗ trợ.

Tôi hy vọng bạn thích thú với thông tin chi tiết nhỏ này về những bước tiến hành xây dựng một sản phẩm web3 và hy vọng nếu bản alpha thành công, tôi sẽ quay lại để chia sẻ những bước tiếp theo trong hành trình xây dựng một web3 thực sự riêng tư.

Trưởng nhóm sản phẩm Steven Nonis
RPCh