Fluffy client: ไคลเอนต์ที่เบามากสำหรับ Ethereum
เราจะออกแบบเครือข่ายได้อย่างไรเพื่อให้ไคลเอนต์ต้องการข้อมูลเพียงเล็กน้อยในเครือข่าย เพื่อให้เครือข่ายทั้งหมด (การสนับสนุนเหล่านี้) มีความหมายมากมาย
—— Piper Merriam
เรามีความยินดีที่จะประกาศว่า Nimbus จะเข้าร่วมทีม "Portal Network" ของ Ethereum Foundation ในฐานะหนึ่งในลูกค้าเปิดตัวของ Portal Network
สรุปหนึ่งประโยค: "Portal Network" เป็นโครงการข้ามไคลเอ็นต์ภายใต้การพัฒนาเพื่อปรับเปลี่ยนไคลเอ็นต์แบบไลท์ของ Ethereum และพัฒนาประสบการณ์ไคลเอนต์แบบไลท์ที่ใช้งานได้และใช้งานได้จริง
หากต้องการอ้างอิงข้อมูลจำเพาะโดยตรง:
"Portal Network" เป็นโครงการที่อยู่ระหว่างการพัฒนาเพื่อให้สามารถเข้าถึงโปรโตคอลได้ไม่มากสำหรับอุปกรณ์ที่มีทรัพยากรจำกัด
คำว่า "เกตเวย์" หมายความว่าเครือข่ายเหล่านี้สามารถสังเกตสถานะที่เป็นอยู่ของการทำงานของโปรโตคอล แต่ไม่แยแสกับการทำงานของโปรโตคอล Ethereum หลัก
เครือข่ายพอร์ทัลจะประกอบด้วยเครือข่ายแบบเพียร์ทูเพียร์แบบกระจายศูนย์หนึ่งเครือข่ายหรือมากกว่า ซึ่งรวมข้อมูลและฟังก์ชันที่จำเป็นในการเปิดเผย JSON-RPC API มาตรฐาน
เครือข่ายเหล่านี้ได้รับการออกแบบมาเป็นพิเศษเพื่อให้แน่ใจว่าไคลเอนต์เหล่านี้ต้องจ่ายเพียงแบนด์วิดท์เครือข่ายขั้นต่ำ, CPU, RAM และทรัพยากรฮาร์ดดิสก์เชิงกลเพื่อเข้าร่วม
คำว่า "เครือข่ายพอร์ทัล" ยังใช้เพื่ออธิบายซอฟต์แวร์ที่เข้าร่วมในเครือข่ายเหล่านี้และเปิดเผยมาตรฐาน JSPN-PRC API
โดยเฉพาะอย่างยิ่ง เป้าหมายของเราคือการทำงานร่วมกับ EF เพื่อพัฒนาโปรโตคอล Ethereum ชุดใหม่รอบโปรโตคอล Ethereum ที่มีอยู่ ซึ่งสามารถรองรับวิธีการใหม่นี้ในการเข้าถึงข้อมูล Ethereum ได้โดยเฉพาะ
เป้าหมายโดยรวมคือการจัดหารูปแบบการดำเนินงานสำหรับ Ethereum ที่สามารถให้บริการรูปแบบการใช้งานทั่วไป แทนที่จะติดตามสถานะทั้งหมดแบบเรียลไทม์ (ซึ่งเป็นสิ่งที่ไคลเอนต์ปัจจุบันทำ)
สิ่งที่เรากำลังพูดถึงคือการพัฒนาไคลเอ็นต์ที่สมบูรณ์แบบสำหรับกระเป๋าเงิน ซึ่งเป็นไคลเอ็นต์ขนาดเล็กมากที่สามารถสนับสนุนเครือข่ายได้ แต่ไม่จำเป็นต้องซิงโครไนซ์บล็อกเชน (นั่นคือสามารถเริ่มต้นใหม่ได้หลังจากออฟไลน์ และหลังการติดตั้งจะพร้อมใช้งานทันที)
นอกจากนี้ยังไม่ยากอย่างที่คิด ฉันคิดว่ากระเป๋าเงินส่วนใหญ่จะฝังไคลเอ็นต์แบบไลท์โดยตรง เช่น @ethstatus จะรวมไคลเอนต์แบบเบา @ethnimbus ดังนั้นอาจมีสถานการณ์ที่ผู้ใช้ส่วนใหญ่เริ่มใช้งานไคลเอ็นต์แบบไลท์โดยไม่รู้ตัว
May 24, 2021
หนึ่งในเป้าหมายสูงสุดของเราคือการให้ลูกค้าประเภทนี้เข้าถึงแอปสถานะได้โดยตรง
พื้นหลัง
พื้นหลัง
เครือข่ายพอร์ทัลมีรากฐานมาจากเป้าหมายดั้งเดิมของนักพัฒนา Piper Merriam และทีม Trinity เพื่อพัฒนาไคลเอนต์น้ำหนักเบาบนเครือข่ายที่มีอยู่ เกิดขึ้นเนื่องจากพวกเขาตระหนักว่าเครือข่ายที่มีอยู่ไม่ยืดหยุ่นเพียงพอสำหรับประเภทไคลเอนต์ที่พวกเขามองเห็น
ในคำพูดของไพเพอร์:
เมื่อเราเริ่มพัฒนาไคลเอนต์ Trinity เป้าหมายของเราคือการพัฒนาไคลเอ็นต์ที่มีน้ำหนักเบา แต่หลังจากใช้เวลาเกือบสามปีในการทำความเข้าใจโปรโตคอลในเชิงลึกและสำรวจวิธีพัฒนาไคลเอนต์ที่เราจินตนาการไว้ ในที่สุดเราก็ได้ข้อสรุปว่าไม่สามารถทำได้บนเครือข่ายที่มีอยู่
นี่คือความตั้งใจดั้งเดิมของเครือข่ายพอร์ทัล เราจะย้อนกลับไปยังสิ่งที่เราต้องการให้ไคลเอนต์มีลักษณะอย่างไร จากนั้นจึงออกแบบการทำงานของเครือข่ายที่จำเป็นเพื่อให้ไคลเอนต์ทำงานได้
ชื่อระดับแรก
แรงจูงใจ (มุมมองลูกค้าเบาๆ)
เครือข่าย DevP2P LES ที่มีอยู่ได้รับการออกแบบด้วยสถาปัตยกรรมแบบไคลเอ็นต์/เซิร์ฟเวอร์ โดยมีไคลเอนต์แบบไลท์เป็นไคลเอ็นต์และโหนดแบบเต็มเป็นเซิร์ฟเวอร์ (จนถึงตอนนี้ คำว่า "ไคลเอ็นต์แบบไลท์" หมายถึงไคลเอ็นต์ DevP2P LES ที่มีอยู่ของเครือข่าย)
เนื่องจากสถาปัตยกรรมนี้กำหนดโหลดทั้งหมดให้กับโหนดแบบเต็ม และค่าใช้จ่ายในการดำเนินการของโหนดแบบเต็มนั้นสูงอยู่แล้ว ดังนั้นตัวดำเนินการโหนดจึงลังเลที่จะเปิดใช้งานฟังก์ชันนี้
ดังนั้น แม้ว่าการออกแบบเครือข่ายปัจจุบันจะบรรลุเป้าหมายเดิมได้ดี แต่ก็ล้มเหลวอย่างเลวร้ายจากมุมมองของไคลเอนต์ขนาดเล็ก
เราจะแก้ปัญหานี้อย่างไร? เมื่อทีม Trinity ของไพเพอร์ค้นพบ ความเป็นจริงแสดงให้เห็นว่าไม่มีทางแก้ปัญหานี้ได้ง่ายๆ เครือข่ายที่มีอยู่ไม่ยืดหยุ่นเพียงพอสำหรับการออกแบบไลท์ไคลเอ็นต์ที่มีประสิทธิภาพ
ชื่อระดับแรก
ออกแบบ
เครือข่ายที่เป็นมิตรกับไคลเอนต์ขนาดเล็กต้องได้รับการออกแบบเพื่อให้โหนดสามารถมีส่วนร่วมในเครือข่ายและสนับสนุนเครือข่ายด้วยพื้นที่จัดเก็บเพียงเล็กน้อยและงานจำนวนน้อย แทนที่จะกำหนดให้แต่ละโหนดต้องรับภาระสูง (เช่น : ในประวัติทั้งหมดของ blockchain จะถูกเก็บไว้ในหน่วยความจำ)
กล่าวอีกนัยหนึ่ง เครือข่ายดังกล่าวต้องอนุญาตให้ไคลเอนต์แบบไลท์มีส่วนร่วมกับเครือข่ายได้ เช่น ทุกครั้งที่มีไคลเอ็นต์เพิ่มเติมเข้าร่วมเครือข่าย จะเป็นการเพิ่มความจุของเครือข่าย
โดยเฉพาะอย่างยิ่ง นี่หมายถึงการออกแบบเครือข่ายที่ลดค่าใช้จ่ายในการตรวจสอบความถูกต้องของข้อมูลที่ขอเป็นระยะๆ ของคุณ และลดค่าใช้จ่ายพื้นฐานในการส่งข้อความผ่านเครือข่าย
เครือข่ายพอร์ทัลมีเป้าหมายที่จะทำเช่นนี้โดยแบ่งโครงสร้างโดยรวมของโปรโตคอล Ethereum ออกเป็นสามเครือข่ายแยกกัน: สถานะและประวัติของ Gossip (ธุรกรรมและการบล็อก) การพัฒนาเริ่มต้นมุ่งเน้นไปที่เครือข่ายของรัฐ
เครือข่ายเหล่านี้จะอยู่ร่วมกับโปรโตคอล ETH แต่ไม่เหมือนโปรโตคอล ETH ตรงที่ไม่จำเป็นต้องคงกระพันอย่างสมบูรณ์ แต่จำเป็นต้องสามารถทำงานได้โดยแทบไม่หยุด
ความหวังก็คือเครือข่ายใหม่เหล่านี้เมื่อเวลาผ่านไปสามารถรวมเข้ากับเครือข่ายที่มีอยู่อย่างแน่นแฟ้นยิ่งขึ้น ตัวอย่างเช่น เราสามารถจินตนาการถึงโลกที่ไคลเอนต์ที่มีคุณสมบัติครบถ้วนสามารถใช้เครือข่ายของพอร์ทัลประวัติเพื่อให้ผู้ให้บริการโหนดมีตัวเลือกเพิ่มเติมในการจัดเก็บเฉพาะประวัติที่พวกเขาสนใจ (อาจจะ 200 MB) แทนที่จะเป็นบล็อกเชนทั้งหมด (มากกว่า 200 กิกะไบต์). เช่นเดียวกับข้อมูลของรัฐ
สรุปแล้ว สถาปัตยกรรมโมดูลาร์นี้ - ที่ซึ่งข้อมูล (สถานะและประวัติบล็อกเชน) ถูกแบ่งปันในรูปแบบ P2P ในขณะที่ธุรกรรมและบล็อกถูกเผยแพร่ผ่านข่าวซุบซิบ - ช่วยให้ลูกค้ารายย่อยสามารถเลือกสถานะในการจัดเก็บ/ให้บริการข้อมูลและข้อมูลประวัติได้
ชื่อระดับแรก
หมายเหตุ JSON RPC
แปลภาษาจีนแปลภาษาจีน): กระเป๋าเงินส่วนใหญ่ รวมถึงของเรา สร้างมาตรฐานบน JSON RPC API
การทำงานที่ถูกต้องของ Status wallet นั้นต้องการปลายทาง JSON RPC ต่อไปนี้:
eth_blockNumber ใช้เพื่อติดตามด้านบนของห่วงโซ่
eth_getBalance และ eth_getTransactionCount ใช้เพื่อขอรับข้อมูลบัญชี
eth_call ใช้เพื่ออ่านข้อมูลสัญญา
eth_estimateGas และ eth_gasPrice ใช้ในการประมาณค่าก๊าซ
eth_sendRawTransaction ใช้เพื่อส่งธุรกรรมของผู้ใช้
eth_getTransactionReceipt รับใบเสร็จหลังจากธุรกรรมออนไลน์
หากเราแยกแยะส่วนประกอบที่จำเป็นเพิ่มเติมเพื่อใช้งานฟังก์ชั่นกระเป๋าเงิน เราจะได้รับข้อกำหนดระดับล่างดังต่อไปนี้:
เข้าถึงรายการจัดเก็บบัญชีและสัญญา (สถานะ) เพื่อรองรับ: eth_call, eth_estimateGas, eth_getBalance และ eth_getTransactionCount
เข้าถึงเครือข่ายซุบซิบ (Gossip) เพื่อติดตามห่วงโซ่และ eth_sendRawTransaction
ประวัติห่วงโซ่การเข้าถึง (ประวัติ) ใช้สำหรับ eth_getTransactionReceipt
Portal Networks เปิดให้เข้าถึงสถานะ การซุบซิบ และประวัติเพียงเล็กน้อย เปิดประตูสู่ไคลเอ็นต์แบบเบาที่ฝังกระเป๋าเงินได้ ซึ่งสามารถตอบสนองความต้องการเหล่านี้ได้โดยไม่ต้องซิงค์บล็อกเชนหรือเสียสละความเป็นส่วนตัวและเพศความปลอดภัย
ชื่อระดับแรก
สถานะโครงการ
เราได้เริ่มพัฒนาโหมดการทำงานสำหรับ Nimbus ซึ่งแต่เดิมชื่อ nlpn แต่ตอนนี้เปลี่ยนชื่อเป็น fluffy ซึ่งจะมีอยู่และทำงานควบคู่ไปกับไคลเอนต์ Ethereum 1
ปุยจะทำให้ไคลเอนต์ nimbus-eth1 ทำงานเป็นโหนดไคลเอนต์ที่เบามากในเครือข่าย
งานเริ่มต้นคือการพัฒนาโปรโตคอล Portal Wire ซึ่งเป็นโปรโตคอลรองที่สร้างขึ้นบนโปรโตคอล Node Discovery v5.1
ขั้นตอนต่อไป
ขั้นตอนต่อไป
ขั้นตอนต่อไปคือการถ่ายโอนข้อมูลผ่านโปรโตคอล Portal Wire เรากำลังจัดการกับข้อมูลของรัฐ
สิ่งนี้ต้องการ "โหนดบริดจ์" เพื่อป้อนข้อมูลสถานะสำหรับเครือข่ายพอร์ทัล แนวทางปัจจุบันคือการใช้ปลั๊กอินไคลเอ็นต์ Nethermind เป็น JSON-PRC API ที่กำหนดเองเพื่อให้ข้อมูลแก่พอร์ทัลโหนดที่เต็มใจทำหน้าที่เป็นโหนดบริดจ์ งานนี้ได้เริ่มขึ้นแล้ว (ร่างข้อกำหนดที่นี่)
ชื่อระดับแรก
ทรัพยากร
Nimbus Portal Network Client (nlpn) สามารถพบได้ในที่เก็บ nimbus-eth1 ของเรา: https://github.com/status-im/nimbus-eth1/tree/master/fluffy
โปรโตคอล Portal Wire ได้ถูกเพิ่มไปยัง nim-eth codebase เป็นโปรโตคอลสำรองสำหรับโปรโตคอลการค้นหาโหนด v5.1: https://github.com/status-im/nim-eth
ข้อมูลจำเพาะ: https://github.com/ethereum/stateless-ethereum-specs/
เว็บไซต์: https://www.ethportal.net/
บางสิ่งเกี่ยวกับการทดสอบโปรโตคอล Portal Wire ครั้งแรกด้วย ddht และ trin: https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53
ชุดบล็อกโดย Piper Merriam: ถนนที่คดเคี้ยวสู่ไคลเอนต์ขนาดเล็กที่ใช้งานได้
วิดีโอบรรยายในหัวข้อ
หมายเหตุ: เพื่อความสะดวก โครงสร้างพื้นฐานทั้งหมดที่จำเป็นในการปรับใช้ไคลเอ็นต์แบบใช้งานน้อยจะขยายไปยังไคลเอนต์ไร้สัญชาติด้วย ดังนั้นจะมีความซ้ำซ้อนมากมายกับไร้สถานะของ Ethereum ในความเป็นจริง การเปิดใช้งานไคลเอนต์ไร้สัญชาติเพื่อให้บริการ JSON-PRC API ส่วนใหญ่เป็นหนึ่งในแรงจูงใจหลักของเครือข่ายพอร์ทัล
