คอขวดและอุปสรรคในการพัฒนา Dapps บน Ethereum คืออะไร

หมายเหตุบรรณาธิการ: บทความนี้มาจากค่ายบล็อคเชน (ID: blockchain_camp)หมายเหตุบรรณาธิการ: บทความนี้มาจาก

ค่ายบล็อคเชน (ID: blockchain_camp)

ค่ายบล็อคเชน (ID: blockchain_camp)

แอปพลิเคชั่นแบบกระจายอำนาจ (Dapps) ได้รับการยอมรับอย่างกว้างขวางว่าเป็นนวัตกรรมที่ก่อกวนในด้านต่าง ๆ เช่น การธนาคาร (Di-Fi) และเกม แต่ถึงกระนั้นโซลูชั่นที่เป็นนวัตกรรมใหม่ที่สุดก็ไม่เป็นที่รู้จักหากไม่เป็นไปตามความคาดหวังของผู้บริโภค

สิ่งที่ผู้บริโภคต้องการคือประสบการณ์การใช้งานที่ราบรื่นและเป็นผู้ใหญ่ และการบรรลุเป้าหมายนี้ก็เป็นอีกหนึ่งความท้าทายที่สำคัญสำหรับนักพัฒนา Ethereum Dapp

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

• ชื่อเรื่องรอง

• สถาปัตยกรรม Ethereum Dapp แบบคลาสสิก

• โดยทั่วไปแล้ว Dapp บน Ethereum ประกอบด้วยสามส่วนหลัก:

โค้ดส่วนหน้าเขียนด้วยภาษาจาวา

แบ็กเอนด์ - โดยทั่วไปจะเป็นโหนด Ethereum blockchain มาตรฐาน การสื่อสารระหว่างส่วนหน้าและส่วนหลังโดยทั่วไปจะใช้ JSON-RPC หรือ GraphQL API ที่โหนดให้มา

ชื่อเรื่องรอง

โหนดแบ็กเอนด์ที่สร้างขึ้นเอง

ในยุคแรก ๆ ของ Ethereum นักพัฒนาต้องใช้งานโหนด Ethereum ของตนเอง หลังจากปล่อย Dapp แล้ว พวกเขาจะต้องดำเนินการโหนดระดับการผลิต (หรือคลัสเตอร์ของโหนด) ด้วย การใช้งานโหนดบล็อกเชนนั้นเป็นภาระงานหนักและยังเป็นภาระต่อประสิทธิภาพของนักพัฒนาอีกด้วย

โหนดเป็นผู้ให้บริการ (NaaS)

ความท้าทายดังกล่าวได้นำไปสู่การเพิ่มขึ้นของแพลตฟอร์ม "node-as-a-service" จากบริษัทต่างๆ เช่น Infura และบริษัทที่ค่อนข้างใหม่กว่า เช่น Nodesmith, Quiknode, Blockdaemon, Ethernode, Chainstack, Alchemy, CloudFlare และอื่นๆ

แพลตฟอร์มเหล่านี้ช่วยให้นักพัฒนามีโหนด Ethereum บนคลาวด์ ซึ่งช่วยนักพัฒนาไม่ต้องพยายามโหนดปฏิบัติการ โซลูชันสำหรับการพัฒนาและการผลิต แพลตฟอร์มเหล่านี้ลดภาระการจัดการระบบ เช่น แพตช์และการอัปเดตสำหรับระบบปฏิบัติการพื้นฐานและซอฟต์แวร์โหนดให้กับนักพัฒนา

ชื่อเรื่องรอง

ข้อ จำกัด โดยธรรมชาติของโหนด Ethereum

แม้ว่าบริการโหนดจะสามารถแทนที่นักพัฒนาในฐานะผู้ดูแลระบบได้สำเร็จ แต่ก็ไม่สามารถช่วยให้นักพัฒนาได้รับประสบการณ์ผู้ใช้ที่ดีขึ้นเพื่อสร้าง Dapp ที่ดีขึ้นได้ เนื่องจากสถาปัตยกรรมจากบริการโหนดและ JSON-RPC และข้อจำกัดโดยธรรมชาติของอินเทอร์เฟซ GraphQL

ข้อ จำกัด ที่สำคัญ ได้แก่ :

1. ข้อมูลสถานะที่สังเกตไม่สอดคล้องกัน

• เพื่อที่จะปรับขนาดเกินความจุของโหนดเดียวในขณะที่ให้ความน่าเชื่อถือที่สูงขึ้น โหนดในฐานะแพลตฟอร์มบริการจะให้การเข้าถึง Node Pool ผ่านตัวจัดสรรภาระงาน

• เนื่องจากโหนดเหล่านี้ทั้งหมดทำงานโดยอัตโนมัติในฐานะโหนดเพียร์ในเครือข่าย Ethereum เมื่อข้อมูลถูกส่งผ่านเครือข่าย ณ ช่วงเวลาหนึ่ง โหนดที่แตกต่างกันอาจอยู่ที่ความสูงของบล็อกที่แตกต่างกัน หรือแม้แต่ที่ทางแยกที่ต่างกัน ซึ่งหมายความว่า Dapp อาจได้รับข้อมูลที่ไม่สอดคล้องกันเกี่ยวกับสถานะของ blockchain เนื่องจากผลลัพธ์ของคำขอนั้นให้บริการโดยโหนดต่างๆ ที่อยู่เบื้องหลังโหลดบาลานเซอร์

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

เมื่อส่วนหน้าสร้างคำขอมากกว่าโหนดส่วนหลังเดียวที่สามารถจัดการได้

เมื่อปัญหาเครือข่ายทำให้ส่วนหน้าตัดการเชื่อมต่อจากส่วนหลังและต้องเชื่อมต่อใหม่

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

• จากนั้นจึงเป็นเรื่องยากสำหรับ Dapp ที่จะจัดการกับการปรับโครงสร้างห่วงโซ่ เนื่องจากส่วนหน้ามักจะเข้าถึงโหนดส่วนหลังหลายโหนด และสถานะของบล็อกเชนที่ได้รับจากโหนดส่วนหลังเหล่านี้ไม่สอดคล้องกัน เมื่อติดตามย้อนหลัง chain history Dapp อาจพบว่าบล็อกพาเรนต์ที่กำลังมองหาไม่มีอยู่อีกต่อไป (เพราะตอนนี้กำลังโต้ตอบกับโหนดอื่นบน fork อื่น) จากนั้นนักพัฒนา Dapp จะต้องเขียนโค้ดเพื่อแก้ปัญหานี้ (โดยปกติจะเชื่อมต่อใหม่ซ้ำๆ จนกว่าจะพบโหนด) สิ่งนี้จะเพิ่มความซับซ้อนโดยไม่จำเป็นให้กับ Dapp และอาจส่งผลให้เกิดความแตกต่างในข้อมูลที่นำเสนอต่อผู้ใช้

• 2. การค้นหาข้อมูลบนบล็อกเชนทำได้ช้าและจำกัด

• Dapps มีข้อจำกัดในความสามารถในการค้นหาธุรกรรมหรือประวัติบนเครือข่าย เนื่องจากโหนด Ethereum มาตรฐานไม่เหมาะที่จะสนับสนุนการค้นหาที่แม่นยำหรือทำการกรองข้อมูลตามเวลาจริง ในการทำเช่นนี้อย่างมีประสิทธิภาพ เราจำเป็นต้องจัดทำดัชนีบล็อกและธุรกรรมหลายล้านรายการ แต่:

• โหนด Ethereum จัดทำดัชนีเฉพาะบางฟิลด์ในบันทึกที่ส่งโดยการทำธุรกรรม (ฟิลด์ที่จะทำดัชนีจะต้องทำเครื่องหมายโดยผู้พัฒนาเมื่อปรับใช้สัญญา)

• โหนด Ethereum ไม่จัดทำดัชนีข้อมูลสำหรับการทำธุรกรรมภายใน (ซึ่งเกิดขึ้นเมื่อสัญญาอัจฉริยะเรียกวิธีการของสัญญาอื่น)

• นักพัฒนาลังเลที่จะเพิ่มฟิลด์ดัชนีเพิ่มเติม เนื่องจากต้นทุนของธุรกรรมแต่ละรายการจะเพิ่มขึ้นสำหรับฟิลด์ดัชนีเพิ่มเติมแต่ละฟิลด์ ซึ่งจะทำให้ผู้ใช้ตามสัญญามีค่าใช้จ่ายเพิ่มเติม

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

ไวยากรณ์การค้นหาที่มีอยู่จำกัดมาก - สนับสนุนเฉพาะการเลือกพื้นฐานและการแทนที่อย่างง่ายเท่านั้น

การดึงผลการค้นหาทำได้ช้า การค้นหาในบล็อกขนาดใหญ่อาจใช้เวลาหลายชั่วโมง

JSON-RPC เป็นการสิ้นเปลืองแบนด์วิธอย่างมาก - ส่งคืนข้อมูลมากกว่าที่คุณต้องการจริงๆ อินเทอร์เฟซ GraphQL ใช้แบนด์วิดท์น้อยกว่า แต่ไม่มีความสามารถในการสตรีม (ส่วนหน้าต้องทำแบบสำรวจความคิดเห็นสำหรับการอัปเดต)

3. ขาดปรมาณู

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

4. โหนดเป็นแบบพาสซีฟ

โหนด Ethereum เป็นแบบพาสซีฟ หมายความว่าไม่สามารถสร้างเหตุการณ์หรือเรียกกลับและเรียกใช้เว็บฮุคได้ การดำเนินการทั้งหมดต้องเริ่มต้นโดยฟรอนต์เอนด์ ซึ่งจะต้องสำรวจโหนดสำหรับข้อมูลที่อัปเดต ความสามารถในการอ่านสตรีมเหตุการณ์ของโหนด Ethereum นั้นจำกัดเกินกว่าจะตอบสนองความต้องการของ Dapps ส่วนใหญ่ได้ และใช้ได้เฉพาะในอินเทอร์เฟซ JSON-RPC ไม่ใช่อินเทอร์เฟซ GraphQL

ชื่อเรื่องรอง

ทบทวนโครงสร้างพื้นฐานของ Dapp

สิ่งที่ dfuse มีให้คือแพลตฟอร์มสำหรับ blockchain APIs ระดับสูงที่ทำให้พวกเขาทำงานได้ง่ายขึ้นกว่า API ดั้งเดิมที่จัดทำโดยโหนด blockchain ได้รับการออกแบบบนพื้นฐานของการมอบฟังก์ชันที่จำเป็นสำหรับนักพัฒนา Dapp ในการสร้างแอปพลิเคชันบล็อกเชนที่ทันสมัยผ่านอินเทอร์เฟซที่รวดเร็วและราบรื่น จึงมอบประสบการณ์ผู้ใช้ที่ยอดเยี่ยม

หวังว่าผ่านแพลตฟอร์ม ข้อจำกัดทั้งหมดที่กล่าวถึงข้างต้นสามารถแก้ไขได้ และข้อจำกัดของโหนด Ethereum แบบดั้งเดิมสามารถถูกทำลายได้

1. มุมมองที่สอดคล้องกัน

dfuse เป็นแพลตฟอร์มข้อมูลแบบไฮเปอร์สเกลแบบบูรณาการ ไม่ใช่ชุดของโหนด Ethereum หลายโหนดบนโหลดบาลานเซอร์ แพลตฟอร์ม dfuse ให้ข้อมูลสถานะลูกโซ่ในการเชื่อมต่อทั้งหมดและทุกจุดในเวลา ไม่ว่าจะเห็นบล็อก (ตรวจพบทั้ง chain fork และการจัดโครงสร้างใหม่) หรือไม่รายงานบล็อกเลย (ในกรณีของบล็อกที่อยู่ระหว่างการปรับโครงสร้างใหม่อย่างรวดเร็วและไม่ได้เดินทางไกล)

• ด้วยวิธีนี้ Dapp จะไม่ต้องเผชิญกับมุมมองที่ไม่สอดคล้องกันของสถานะห่วงโซ่ และสามารถมุ่งเน้นไปที่หน้าที่หลักแทนที่จะต้องวุ่นวายกับการตรวจสอบรายละเอียดของบล็อกเชน

• 2. การค้นหาแบบละเอียดด้วยความเร็วสูง

• ช่วยให้นักพัฒนา Dapp สามารถค้นหาบันทึกประวัติของบล็อกเชนด้วยความละเอียดที่ละเอียดมาก ความเร็ว และประสิทธิภาพที่ไม่ธรรมดา นอกจากนี้ ยังสามารถใช้การกรองตามเวลาจริงและการอ่านแบบสตรีมผ่านอินเทอร์เฟซ GraphQL, gRPC และ Websocket

• จัดทำดัชนีฟิลด์บันทึกทั้งหมดอย่างสมบูรณ์ - ข้อมูลทั้งหมดที่ปล่อยออกมาจากแต่ละธุรกรรมในบันทึกนั้นนำไปใช้โดยตรงกับการค้นหาที่มีความแม่นยำสูง

• การจัดทำดัชนีธุรกรรมภายในทั้งหมด (ผู้ส่ง ผู้รับ ค่า วิธีการ พารามิเตอร์อินพุต) อย่างครบถ้วน จึงติดตามการดำเนินการของสัญญาในโครงสร้างแบบต้นไม้ของการโทรทั้งหมดได้อย่างสมบูรณ์

• การจัดทำดัชนีไม่มีค่าใช้จ่ายเพิ่มเติมสำหรับผู้ใช้ของคุณ - การจัดทำดัชนีของ dfuse เป็นคุณลักษณะแบบบูรณาการของแพลตฟอร์ม dfuse และไม่เพิ่มต้นทุนทรัพยากรของการดำเนินการตามสัญญา

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

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

ให้ประสิทธิภาพที่ยอดเยี่ยม - ในเวลาน้อยกว่าหนึ่งวินาทีตามเกณฑ์การค้นหาที่ระบุ ค้นหาประวัติเชนทั้งหมดเพื่อค้นหาชุดของการจับคู่ที่ตรงทั้งหมด

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

ประสิทธิภาพนั้นสอดคล้องกันโดยไม่คำนึงถึงทราฟฟิกบนเครือข่าย Ethereum

3. ปฏิบัติการปรมาณู

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

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

• เร็ว

• 5. แพลตฟอร์มที่ทันสมัยที่สร้างขึ้นสำหรับ Dapps ที่ล้ำสมัย

• dfuse มีชั้นโครงสร้างพื้นฐานที่ทันสมัยสำหรับ Dapp ของคุณ ได้แก่:

• เร็ว

• ปรับขนาดได้

• ให้การเข้าถึงเหตุการณ์ blockchain แบบเรียลไทม์ที่มีความแม่นยำสูงและละเอียด

รองรับการโทรกลับในรูปแบบของ Webhooks