Chúng tôi trở về từ Colombia với một đội mới và một động lực mới. RPCh sẽ là sản phẩm đầu tiên trên HOPR — một trường hợp sử dụng rõ ràng cho giao thức không chỉ cung cấp một bản nâng cấp mơ hồ về quyền riêng tư mà còn giải quyết vấn đề khẩn cấp và kịp thời trong web3. Người dùng hào hứng, ví tiền hào hứng, chúng tôi hào hứng.

Nhưng bây giờ công việc thực sự cần phải bắt đầu, và nhanh chóng. Chúng tôi đã hợp tác với nửa tá ví trong tháng trước, tất cả đều mong muốn cung cấp cho người dùng quyền riêng tư thông qua RPCh thông qua tích hợp trực tiếp vào giao diện người dùng của họ. Đây là một sự thúc đẩy to lớn cho HOPR, nhưng những thỏa thuận này phụ thuộc vào việc một giải pháp sẽ sẵn sàng trong vài tháng chứ không phải vài năm.

tiêu hóa kiến ​​trúc

Cuộc thi hackathon đã tạo ra một bằng chứng tuyệt vời về khái niệm, nhưng nó còn lâu mới là một sản phẩm, hay thậm chí là một bản thiết kế cho một sản phẩm. Phiên bản RPCh đó yêu cầu người dùng cung cấp mọi thứ - máy chủ RPC, nút HOPRd - chính họ.

Nó đã hoạt động, đó vẫn là một thành tựu to lớn, nhưng nó không phải là một sản phẩm hay dịch vụ. Với thiết lập đó, chúng tôi nên trả tiền cho người dùng chứ không phải ngược lại!

Và đó thực sự là câu hỏi đầu tiên trong số rất nhiều câu hỏi mà chúng tôi không thể trì hoãn lâu hơn nữa. Ai sẽ trả tiền cho RPCh? Đây có phải là thứ mà người dùng sẽ trả tiền, có lẽ là một khoản phí bổ sung cho tiền xăng? Hay ví sẽ trả tiền và hấp thụ chi phí hoặc chuyển chúng cho người dùng bằng cách nào đó?

Nghiên cứu nội bộ của chúng tôi cho thấy rằng người dùng nói rằng họ sẵn lòng trả tiền, nhưng đây luôn là vấn đề với quyền riêng tư: mọi người đều tuyên bố rằng họ muốn điều đó, nhưng khi gặp khó khăn thì rất ít người sẵn sàng làm bất cứ điều gì để giải quyết vấn đề đó.

Người ta nhanh chóng quyết định rằng RPCh sẽ được nhắm mục tiêu đến các ví như một bản nâng cấp cho giải pháp RPC hiện tại của họ.

Nhưng điều này đã có ý nghĩa rất lớn: nếu bạn đang cung cấp các gói dịch vụ, chẳng hạn như 10 triệu cuộc gọi RPC mỗi tháng, thì bạn cần một cách để ấn định hạn ngạch này, theo dõi hạn ngạch đó và giới hạn dịch vụ khi hết hạn ngạch. Kiến trúc cho một hệ thống như vậy sẽ hoàn toàn khác với kiến ​​trúc mà RPCh được thanh toán cho mỗi giao dịch. Chưa kể đến các hiệu ứng dây chuyền về cách RPCh sẽ được truyền đạt và tiếp thị.

Và đây chỉ là một trong nhiều góc độ cần xem xét, mỗi góc độ đều có những hậu quả và hạn chế riêng đối với thiết kế.

Nó có vẻ như là một thách thức quá sức, nhưng một trong những phần hài lòng nhất của thiết kế phần mềm là chia nhỏ một vấn đề khổng lồ thành các nhiệm vụ ngày càng rõ ràng và dễ quản lý hơn. Không có gì tốt hơn là bắt đầu với một sơ đồ và một giấc mơ và kết thúc với một lộ trình và một danh sách được sắp xếp cho một lần chạy nước rút được đóng gói trong GitHub.

Cho tôi ít nhất :)

Đường đến Lộ trình

Và cũng như mọi thứ tại RPCh, đây là nỗ lực của cả nhóm. Đầu tiên là những cân nhắc cấp cao: RPCh với tư cách là một dịch vụ sẽ như thế nào? Ai sẽ trả tiền? Ai sẽ chạy các nút RPCh và được thưởng? Chúng có khác với các nút HOPR tiêu chuẩn trong hoạt động và khuyến khích của chúng không? Làm sao?

Điều này tạo ra một thiết kế kiến ​​trúc với các thành phần khác nhau và các chức năng cũng như mối quan hệ qua lại của chúng. Tôi không thể công nhận ở đây: hầu hết công việc đã được hoàn thành bởi những người sáng lập và nhóm nòng cốt, vì vậy khi tôi trở lại văn phòng Zurich sau kỳ nghỉ ở Colombia, có một thiết kế kiến ​​trúc cấp cao đang đợi tôi.

Với tư cách là trưởng nhóm sản phẩm, nhiệm vụ của tôi là thực hiện kế hoạch này và biến nó thành một kế hoạch cụ thể để phát triển. Các thành phần khác nhau sẽ được xây dựng như thế nào và chúng ta sẽ xây dựng chúng theo thứ tự nào? Làm thế nào họ sẽ được kiểm tra? Ví sẽ được cấp quyền truy cập như thế nào và khi nào, thông qua SDK hay cách khác?

Và điều quan trọng là ai sẽ được chỉ định xây dựng từng bộ phận?

Bởi vì cùng với tất cả công việc thiết kế này, có một thách thức song song, mặc dù đó là một thách thức cực kỳ bổ ích để giải quyết. Chúng tôi đã thuê Camilo, Diego và Luis — ba người Colombia đã thể hiện rất xuất sắc tại hackathon — làm thành viên của nhóm RPCh mới. Chúng tôi rất ấn tượng với công việc và sự nhiệt tình của họ, nhưng họ vẫn còn tương đối non trẻ, đặc biệt là khi nói đến tiền điện tử. Lịch trình phát triển cho RPCh có nghĩa là hầu hết quá trình giới thiệu của họ sẽ cần diễn ra trong công việc. Họ cũng ở múi giờ hoàn toàn khác với tôi, điều đó có nghĩa là họ cần có khả năng thực hiện các nhiệm vụ mà không bị giám sát trong phần lớn thời gian trong ngày của họ.

Giống như mọi thành viên khác của nhóm HOPR, các tân binh đã trải qua quy trình giới thiệu HOPR tiêu chuẩn, từ việc tìm hiểu các quy trình và công cụ làm việc nhóm khác nhau của chúng tôi cho đến các phiên thực hành Ethereum tuyệt vời từ người sáng lập Sebastian của chúng tôi (mà mọi người tại HOPR đều đảm nhận, bất kể vai trò là gì). hoặc chuyên môn kỹ thuật).

Đây là một cách tuyệt vời để học, nhưng nó cũng có ý nghĩa sâu sắc đối với lộ trình. Như với bất kỳ dự án nào, việc xây dựng RPCh có một số yếu tố phụ thuộc — những thứ phải được xây dựng theo một thứ tự nhất định vì chúng phụ thuộc lẫn nhau. Sau đó, có các phụ thuộc bên ngoài: giao thức HOPR vẫn đang được phát triển, vì vậy chúng tôi cần làm việc theo lộ trình ở đó. Chúng tôi cũng cần lập kế hoạch về cách thức và thời điểm bàn giao RPCh cho các cộng tác viên ví của chúng tôi để tích hợp lần cuối.

Ngoài ra còn có sự phụ thuộc trong nhóm. Mọi người đều có một bộ kỹ năng khác nhau và thật hợp lý khi họ làm việc trên các nhiệm vụ cụ thể. Thật may mắn cho chúng tôi, những tân binh người Colombia đã đến với tư cách là một gói đầy đủ: Diego có nhiều kinh nghiệm nhất trong công việc phát triển và kiến ​​trúc, Camilo có chuyên môn về mặt trước và Luis cảm thấy thoải mái nhất khi xây dựng các hình ảnh Docker khác nhau mà RPCh sẽ dựa vào.

Nhưng hầu hết các ưu tiên có yêu cầu nhẹ nhàng hơn. Thật hợp lý khi xây dựng một số thứ nhất định trước vì nó cho phép chúng tôi đạt được các bộ tính năng khả thi tối thiểu nhanh hơn. Điều này tốt cho việc thử nghiệm và phát hành, nhưng cũng tốt cho sự hiểu biết.

Tôi quyết định chúng tôi sẽ xây dựng các phiên bản hộp cát gia tăng hoặc RPCh, trong đó các phiên bản thô sơ của từng thành phần sẽ được giới thiệu để nhóm có thể thực sự thấy cách mọi thứ tương tác và cách các thành phần riêng lẻ mà họ đang làm việc sẽ kết hợp với nhau. Sau đó, chúng tôi sẽ chuyển sang alpha, beta, v.v., cải thiện và bổ sung các thành phần khi chúng tôi thực hiện.

Chơi ở chế độ cứng

Một trong những cân nhắc quan trọng nhất là tạo ra một đường cong độ khó suôn sẻ cho đội.

Họ đang bắt đầu vai trò tại một công ty mới làm việc trên một công nghệ mới, điều này có thể gây khó khăn. Mặc dù những thất bại là không thể tránh khỏi trong quá trình phát triển phần mềm, nhưng điều rất quan trọng đối với tôi là tạo ra một môi trường mà chúng tôi cảm thấy như mình luôn tiến bộ. Điều này có nghĩa là bắt đầu với kết quả thấp nếu có thể, kỷ niệm các mốc quan trọng như cam kết và PR đầu tiên và tăng độ khó khi chúng tôi di chuyển qua các lần chạy nước rút.

Tôi cũng đã học được từ kinh nghiệm của mình trong nhóm nòng cốt HOPR và chắc chắn sẽ tạo ra các quy trình rõ ràng ngay từ ngày đầu tiên, cũng như thường xuyên tổ chức các buổi hồi tưởng để kỷ niệm những gì đang hoạt động hiệu quả và khắc phục mọi vấn đề trước khi chúng trở thành vấn đề.

Tôi không muốn jinx bất cứ điều gì, nhưng cho đến nay nó dường như đã làm việc. RPCh đã đạt được tất cả các mốc phát triển của mình và nhóm đã nỗ lực nhiều hơn để đáp ứng thách thức leo thang. Sẽ là nói dối khi nói rằng không có trở ngại nào (chúng ta sẽ đề cập đến một số trở ngại đó vào lần tới) nhưng việc lập kế hoạch cẩn thận và các bộ đệm và dự phòng được xây dựng sẵn đã giảm thiểu tác động và chúng tôi đang đi đúng hướng với dòng thời gian đã thỏa thuận với các đối tác ví của chúng tôi vào tháng 10.

Điều này chỉ mới vạch ra những thách thức và cân nhắc khi lập kế hoạch ngay cả đối với một dự án phát triển phần mềm tương đối khiêm tốn như RPCh, nhưng tôi hy vọng sẽ rất thú vị khi thấy một khía cạnh hiếm khi được thảo luận của tiền điện tử.

Trong phần cuối cùng, chúng ta sẽ xem xét cách nhóm RPCh đã mở rộng hơn nữa và một số bài học quan trọng nhất đã học được trong vài tháng qua.

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

Trang mạng:https://www.hoprnet.orgTwitter:https://twitter.com/hoprnetđiện báo:https://t.me/hoprnetbất hòa:https://discord.gg/dEAWC4G

Diễn đàn:https://forum.hoprnet.orgđặt cược:https://stake.hoprnet.orgTiền thưởng:https://bounties.hoprnet.orgSân chơi:https://playground.hoprnet.org