เรากลับมาจากโคลอมเบียพร้อมกับทีมใหม่และไดรฟ์ใหม่ RPCh จะเป็นผลิตภัณฑ์แรกนอกเหนือจาก HOPR ซึ่งเป็นกรณีการใช้งานที่ชัดเจนสำหรับโปรโตคอลซึ่งไม่ได้เพียงแค่ให้การอัปเกรดความเป็นส่วนตัวที่คลุมเครือ แต่ยังแก้ปัญหาเร่งด่วนและทันท่วงทีใน web3 ผู้ใช้ตื่นเต้น กระเป๋าเงินตื่นเต้น เราก็ตื่นเต้น

แต่ตอนนี้งานจริงจำเป็นต้องเริ่มต้นอย่างรวดเร็ว เราปลอมแปลงความร่วมมือกับกระเป๋าเงินกว่าครึ่งโหลเมื่อเดือนที่แล้ว โดยทั้งหมดต่างกระตือรือร้นที่จะให้ความเป็นส่วนตัวแก่ผู้ใช้ผ่าน RPCh ผ่านการผสานรวมเข้ากับ UI ของพวกเขาโดยตรง นี่เป็นการสนับสนุนอย่างมากสำหรับ HOPR แต่ข้อตกลงเหล่านี้ขึ้นอยู่กับโซลูชันที่จะพร้อมในไม่กี่เดือน ไม่ใช่ปี

การแยกย่อยทางสถาปัตยกรรม

แฮ็กกาธอนได้พิสูจน์แนวคิดที่ยอดเยี่ยม แต่ก็ยังห่างไกลจากการเป็นผลิตภัณฑ์หรือแม้แต่พิมพ์เขียวสำหรับหนึ่ง RPCh เวอร์ชันนั้นกำหนดให้ผู้ใช้จัดเตรียมทุกอย่าง — เซิร์ฟเวอร์ RPC, โหนด HOPRd — ด้วยตัวเอง

มันได้ผล ซึ่งยังคงเป็นความสำเร็จที่ยิ่งใหญ่ แต่ไม่ใช่ผลิตภัณฑ์หรือบริการ ด้วยการตั้งค่านั้น เราควรจะจ่ายเงินให้กับผู้ใช้ ไม่ใช่ในทางกลับกัน!

และนั่นเป็นคำถามแรกจากหลายคำถามที่เราไม่สามารถปฏิเสธได้อีกต่อไป ใครจะเป็นผู้จ่ายเงินสำหรับ RPh นี่เป็นสิ่งที่ผู้ใช้ยอมจ่ายหรืออาจจะเป็นค่าธรรมเนียมเพิ่มเติมนอกเหนือจากค่าน้ำมัน? หรือกระเป๋าเงินจะจ่ายและดูดซับค่าใช้จ่ายหรือส่งต่อไปยังผู้ใช้ด้วยวิธีใด

การวิจัยภายในของเราแสดงให้เห็นว่าผู้ใช้กล่าวว่าพวกเขายินดีจ่าย แต่สิ่งนี้มักเป็นปัญหาเกี่ยวกับความเป็นส่วนตัวเสมอ ทุกคนอ้างว่าพวกเขาต้องการ เมื่อพูดถึงประเด็นปัญหา มีเพียงไม่กี่คนที่เต็มใจที่จะทำอะไรกับมัน

มีการตัดสินใจอย่างรวดเร็วว่า RPCh จะกำหนดเป้าหมายไปที่กระเป๋าเงินเพื่ออัปเกรดเป็นโซลูชัน RPC ที่มีอยู่

แต่สิ่งนี้มีผลอย่างมากอยู่แล้ว: หากคุณเสนอแพ็คเกจบริการ เช่น การโทร RPC 10 ล้านครั้งต่อเดือน คุณต้องมีวิธีกำหนดโควต้านี้ ติดตาม และจำกัดบริการเมื่อหมด สถาปัตยกรรมสำหรับระบบดังกล่าวจะแตกต่างอย่างสิ้นเชิงจากระบบที่จ่าย RPCh ต่อการทำธุรกรรม ไม่ต้องพูดถึงผลกระทบต่อวิธีการสื่อสารและทำการตลาดของ RPCh

และนี่เป็นเพียงหนึ่งในหลายๆ มุมมองที่ต้องพิจารณา ซึ่งแต่ละมุมมีผลที่ตามมาและข้อจำกัดในการออกแบบที่แตกต่างกันไป

อาจดูเหมือนเป็นความท้าทายอย่างท่วมท้น แต่ส่วนที่น่าพึงพอใจมากที่สุดประการหนึ่งของการออกแบบซอฟต์แวร์คือการแบ่งปัญหาใหญ่โตออกเป็นงานที่ชัดเจนและจัดการได้มากขึ้น ไม่มีอะไรดีไปกว่าการเริ่มต้นด้วยไดอะแกรมและความฝันและจบลงด้วยโร้ดแมปและรายการคำสั่งสำหรับการวิ่งที่อัดแน่นใน GitHub

สำหรับฉันอย่างน้อย :)

เส้นทางสู่โรดแมป

และเช่นเดียวกับทุกสิ่งที่ RPCh นี่เป็นความพยายามของทีม ประการแรก มีข้อควรพิจารณาในระดับสูง: RPCh ในฐานะบริการจะมีลักษณะอย่างไร ใครจะจ่าย? ใครจะเป็นผู้เรียกใช้โหนด RPCh และได้รับรางวัล สิ่งเหล่านี้จะแตกต่างจากโหนด HOPR มาตรฐานในการดำเนินการและการจูงใจหรือไม่ ยังไง?

สิ่งนี้ทำให้เกิดการออกแบบสถาปัตยกรรมที่มีส่วนประกอบและหน้าที่และความสัมพันธ์ระหว่างกัน ฉันไม่สามารถรับเครดิตได้ที่นี่ งานส่วนใหญ่เสร็จสิ้นโดยผู้ก่อตั้งและทีมงานหลัก ดังนั้นเมื่อฉันกลับไปที่สำนักงานที่ซูริคหลังจากวันหยุดในโคลอมเบีย งานออกแบบสถาปัตยกรรมระดับสูงรอฉันอยู่

ในฐานะหัวหน้าฝ่ายผลิตภัณฑ์ หน้าที่ของฉันคือนำแผนนี้ไปเปลี่ยนเป็นแผนการพัฒนาที่เป็นรูปธรรม ส่วนประกอบต่าง ๆ จะถูกสร้างขึ้นอย่างไร และเราจะสร้างมันตามลำดับใด พวกเขาจะถูกทดสอบอย่างไร? กระเป๋าเงินจะได้รับการเข้าถึงอย่างไรและเมื่อใด ผ่าน SDK หรืออย่างอื่น

และที่สำคัญคือใครจะได้รับมอบหมายให้สร้างแต่ละส่วน?

เนื่องจากงานออกแบบทั้งหมดนี้มีความท้าทายคู่ขนานกัน แม้ว่าจะเป็นสิ่งที่คุ้มค่าอย่างยิ่งที่จะจัดการ เราจ้าง Camilo, Diego และ Luis ซึ่งเป็นชาวโคลอมเบียสามคนที่ทำผลงานได้ดีในงาน Hackathon ให้เป็นสมาชิกของทีม RPCh ใหม่ เราประทับใจมากกับการทำงานและความกระตือรือร้นของพวกเขา แต่พวกเขาก็ยังค่อนข้างเด็ก โดยเฉพาะอย่างยิ่งเมื่อพูดถึงคริปโต ตารางการพัฒนาสำหรับ RPCh หมายความว่าการเริ่มงานส่วนใหญ่จะต้องเกิดขึ้นในงาน พวกเขาอยู่ในเขตเวลาที่แตกต่างกันอย่างสิ้นเชิงสำหรับฉัน ซึ่งหมายความว่าพวกเขาจำเป็นต้องสามารถทำงานส่วนใหญ่ในหนึ่งวันโดยไม่มีผู้ดูแลได้

เช่นเดียวกับสมาชิกในทีม HOPR คนอื่นๆ พนักงานใหม่ต้องผ่านกระบวนการเริ่มต้นใช้งาน HOPR มาตรฐาน ตั้งแต่การเรียนรู้กระบวนการต่างๆ และเครื่องมือการทำงานเป็นทีมไปจนถึงเซสชัน Ethereum ที่ยอดเยี่ยมจาก Sebastian ผู้ก่อตั้งของเรา (ซึ่งทุกคนที่ HOPR รับโดยไม่คำนึงถึงบทบาท หรือความเชี่ยวชาญทางเทคนิค).

นี่เป็นวิธีที่ดีในการเรียนรู้ แต่ก็มีความหมายลึกซึ้งสำหรับแผนการทำงานด้วย เช่นเดียวกับโครงการอื่นๆ การสร้าง RPCh มีการพึ่งพาอาศัยกันบางอย่าง ซึ่งต้องสร้างตามลำดับที่แน่นอนเนื่องจากต้องพึ่งพาอาศัยกัน จากนั้นมีการพึ่งพาภายนอก: โปรโตคอล HOPR ยังอยู่ระหว่างการพัฒนา ดังนั้นเราจำเป็นต้องทำงานภายในแผนงานที่นั่น นอกจากนี้ เรายังจำเป็นต้องวางแผนว่าจะมอบ RPCh ให้กับผู้ทำงานร่วมกันกระเป๋าเงินของเราอย่างไรและเมื่อใดเพื่อการผสานรวมขั้นสุดท้าย

นอกจากนี้ยังมีการพึ่งพาภายในทีม ทุกคนมีทักษะที่แตกต่างกันและเหมาะสมสำหรับพวกเขาในการทำงานเฉพาะอย่าง โชคดีสำหรับเราที่พนักงานใหม่ชาวโคลอมเบียมาถึงในฐานะของแพ็คเกจเต็มรูปแบบ: Diego มีประสบการณ์มากที่สุดในงาน devops และงานสถาปัตยกรรม Camilo มีความเชี่ยวชาญด้าน front-end และ Luis รู้สึกสบายใจที่สุดในการสร้างอิมเมจ Docker ต่างๆ ที่ RPCh ไว้วางใจ

แต่การจัดลำดับความสำคัญส่วนใหญ่มีข้อกำหนดที่นุ่มนวลกว่า การสร้างบางอย่างก่อนเป็นเรื่องที่สมเหตุสมผลเพราะมันช่วยให้เราเข้าถึงชุดคุณลักษณะขั้นต่ำที่ใช้งานได้เร็วขึ้น สิ่งนี้ดีสำหรับการทดสอบและการเผยแพร่ แต่ยังเพื่อความเข้าใจด้วย

ฉันตัดสินใจว่าเราจะสร้างเวอร์ชันแซนด์บ็อกซ์แบบส่วนเพิ่มหรือ RPCh ซึ่งจะมีการแนะนำเวอร์ชันพื้นฐานของแต่ละคอมโพเนนต์ เพื่อให้ทีมสามารถเห็นได้อย่างแท้จริงว่าทุกอย่างมีปฏิสัมพันธ์อย่างไร และคอมโพเนนต์แต่ละตัวที่พวกเขากำลังทำงานอยู่จะรวมเข้าด้วยกันอย่างไร จากนั้นเราจะไปยังอัลฟ่า เบต้า และอื่นๆ ปรับปรุงและเพิ่มส่วนประกอบเมื่อเราดำเนินการไป

เล่นในโหมดฮาร์ด

หนึ่งในข้อพิจารณาที่สำคัญที่สุดคือการสร้างเส้นโค้งความยากที่ราบรื่นสำหรับทีม

พวกเขาเริ่มงานในบริษัทใหม่ที่ทำงานเกี่ยวกับเทคโนโลยีใหม่ ซึ่งอาจเป็นเรื่องที่น่าหวาดหวั่น แม้ว่าความพ่ายแพ้จะเป็นสิ่งที่หลีกเลี่ยงไม่ได้ในการพัฒนาซอฟต์แวร์ แต่การสร้างสภาพแวดล้อมที่เรารู้สึกเหมือนกำลังก้าวหน้าอยู่เสมอเป็นสิ่งสำคัญมากสำหรับฉัน นี่หมายถึงการเริ่มต้นด้วยผลไม้ห้อยต่ำหากเป็นไปได้ ฉลองเหตุการณ์สำคัญ เช่น ความมุ่งมั่นครั้งแรกและการประชาสัมพันธ์ และเพิ่มระดับความยากเมื่อเราเคลื่อนที่ผ่านการวิ่ง

ฉันยังได้เรียนรู้จากประสบการณ์ของฉันในทีมหลักของ HOPR และมั่นใจว่าจะสร้างกระบวนการที่ชัดเจนตั้งแต่วันแรก รวมทั้งมีการประชุมย้อนหลังบ่อยครั้งเพื่อเฉลิมฉลองสิ่งที่ได้ผลและแก้ไขปัญหาใด ๆ ก่อนที่จะกลายเป็นปัญหา

ฉันไม่ต้องการที่จะซวยอะไร แต่จนถึงตอนนี้ดูเหมือนว่าจะได้ผล RPCh ได้บรรลุเป้าหมายการพัฒนาทั้งหมดแล้ว และทีมก็ลุกขึ้นมามากกว่าที่จะรับมือกับความท้าทายที่ทวีความรุนแรงขึ้น มันคงเป็นเรื่องโกหกที่จะบอกว่าไม่มีความพ่ายแพ้ (เราจะพูดถึงบางส่วนในครั้งต่อไป) แต่การวางแผนอย่างรอบคอบและบัฟเฟอร์ที่สร้างขึ้นและความซ้ำซ้อนได้ลดผลกระทบให้เหลือน้อยที่สุด และเราดำเนินการตามกำหนดเวลาที่ตกลงไว้เป็นอย่างดี กับพันธมิตรกระเป๋าเงินของเราย้อนกลับไปในเดือนตุลาคม

นี่เป็นเพียงการขีดข่วนพื้นผิวของความท้าทายและข้อควรพิจารณาในการวางแผนแม้แต่โครงการพัฒนาซอฟต์แวร์ที่ค่อนข้างเจียมเนื้อเจียมตัวอย่าง RPCh แต่ฉันหวังว่ามันน่าสนใจที่ได้เห็นด้านของ crypto ที่ไม่ค่อยมีใครพูดถึง

ในงวดสุดท้าย เราจะมาดูกันว่าทีม RPCh ได้ขยายตัวออกไปอย่างไร และบทเรียนที่สำคัญที่สุดบางส่วนที่ได้เรียนรู้ในช่วงไม่กี่เดือนที่ผ่านมา

Steven Noni
RPh หัวหน้าฝ่ายผลิตภัณฑ์

เว็บไซต์:https://www.hoprnet.orgทวิตเตอร์:https://twitter.com/hoprnetโทรเลข:https://t.me/hoprnetความไม่ลงรอยกัน:https://discord.gg/dEAWC4G

ฟอรั่ม:https://forum.hoprnet.orgการเดิมพัน:https://stake.hoprnet.orgค่าหัว:https://bounties.hoprnet.orgสนามเด็กเล่น:https://playground.hoprnet.org