สวัสดี ฉันทำงานในทีมโครงการ DRD KP (เผยแพร่ข้อมูลรีจิสทรีสำหรับตรวจสอบวงจรชีวิตของชุดล้อ) ที่นี่ฉันอยากจะแบ่งปันประสบการณ์ของทีมงานของเราในการพัฒนาบล็อกเชนระดับองค์กรสำหรับโครงการนี้ภายใต้ข้อจำกัดของเทคโนโลยี โดยส่วนใหญ่ ฉันจะพูดถึง Hyperledger Fabric แต่แนวทางที่อธิบายไว้ที่นี่สามารถอนุมานได้กับบล็อกเชนที่ได้รับอนุญาตใดๆ เป้าหมายสูงสุดของการวิจัยของเราคือการเตรียมโซลูชันบล็อกเชนระดับองค์กรในลักษณะที่ทำให้ผลิตภัณฑ์ขั้นสุดท้ายน่าใช้และไม่ดูแลรักษายากเกินไป
จะไม่มีการค้นพบ วิธีแก้ปัญหาที่ไม่คาดคิด และไม่มีการพัฒนาที่ไม่เหมือนใครจะครอบคลุมที่นี่ (เพราะฉันไม่มี) ฉันแค่อยากแบ่งปันประสบการณ์อันต่ำต้อยของฉันแสดงให้เห็นว่า "เป็นไปได้" และอาจอ่านเกี่ยวกับประสบการณ์ของคนอื่นในการตัดสินใจที่ดีและไม่ดีนักในความคิดเห็น
ปัญหา: บล็อกเชนยังไม่สามารถปรับขนาดได้
ทุกวันนี้ ความพยายามของนักพัฒนาหลายคนมุ่งเป้าไปที่การทำให้บล็อกเชนเป็นเทคโนโลยีที่สะดวกจริงๆ และไม่ใช่ระเบิดเวลาในห่อที่สวยงาม ช่องทางของรัฐ การสะสมในแง่ดี พลาสมา และการแบ่งส่วนอาจกลายเป็นเรื่องธรรมดา สักวันหนึ่ง. หรือบางที TON อาจจะเลื่อนการเปิดตัวออกไปอีกหกเดือน และ Plasma Group ถัดไปก็จะยุติลง เราสามารถเชื่อในแผนงานอื่นและอ่านเอกสารไวท์เปเปอร์ที่ยอดเยี่ยมในตอนกลางคืนได้ แต่ที่นี่และตอนนี้เราจำเป็นต้องทำอะไรบางอย่างกับสิ่งที่เรามี ทำเรื่องบ้าๆ ซะ
งานที่มอบหมายให้กับทีมของเราในโครงการปัจจุบันมีลักษณะเช่นนี้ในแง่ทั่วไป: มีหลายวิชาที่เข้าถึงหลายพันคนที่ไม่ต้องการสร้างความสัมพันธ์บนความไว้วางใจ จำเป็นต้องสร้างโซลูชัน DLT ที่จะทำงานบนพีซีธรรมดาโดยไม่มีข้อกำหนดด้านประสิทธิภาพพิเศษและมอบประสบการณ์ผู้ใช้ที่ไม่เลวร้ายไปกว่าระบบบัญชีแบบรวมศูนย์ใดๆ เทคโนโลยีที่อยู่เบื้องหลังโซลูชันควรลดความเป็นไปได้ของการจัดการข้อมูลที่เป็นอันตรายให้เหลือน้อยที่สุด ซึ่งเป็นเหตุผลว่าทำไมบล็อกเชนถึงอยู่ที่นี่
คำขวัญจากเอกสารไวท์เปเปอร์และสื่อสัญญากับเราว่าการพัฒนาครั้งต่อไปจะอนุญาตให้มีการทำธุรกรรมหลายล้านรายการต่อวินาที จริงๆแล้วมันคืออะไร?
Mainnet Ethereum กำลังทำงานอยู่ที่ ~30 tps ด้วยเหตุนี้เพียงอย่างเดียว จึงเป็นเรื่องยากที่จะมองว่ามันเป็นบล็อกเชนที่เหมาะกับความต้องการขององค์กรในทางใดทางหนึ่ง ในบรรดาโซลูชันที่ได้รับอนุญาต เกณฑ์มาตรฐานที่แสดง 2000 tps เป็นที่รู้จัก () หรือ 3000 ช้อนชา (มีการเผยแพร่น้อยกว่าเล็กน้อย แต่โปรดจำไว้ว่าการวัดประสิทธิภาพได้ดำเนินการกับเครื่องมือฉันทามติแบบเก่า) เคยเป็น ซึ่งไม่ได้ให้ผลลัพธ์ที่แย่ที่สุด คือ 20000 tps แต่จนถึงขณะนี้เป็นเพียงการศึกษาเชิงวิชาการที่รอการนำไปปฏิบัติอย่างมั่นคง ไม่น่าเป็นไปได้ที่บริษัทที่สามารถรักษาแผนกของนักพัฒนาบล็อกเชนจะทนกับตัวบ่งชี้ดังกล่าว แต่ปัญหาไม่ได้อยู่ที่ปริมาณงานเท่านั้น แต่ยังมีเวลาแฝงอีกด้วย
ความแอบแฝง
ความล่าช้าตั้งแต่ช่วงเวลาที่ธุรกรรมเริ่มต้นไปจนถึงการอนุมัติขั้นสุดท้ายโดยระบบนั้นไม่เพียงแต่ขึ้นอยู่กับความเร็วของข้อความที่ส่งผ่านทุกขั้นตอนของการตรวจสอบและการสั่งซื้อเท่านั้น แต่ยังรวมถึงพารามิเตอร์การสร้างบล็อกด้วย แม้ว่าบล็อคเชนของเราจะอนุญาตให้เรากระทำที่ 1000000 tps แต่ต้องใช้เวลา 10 นาทีในการสร้างบล็อกขนาด 488MB มันจะง่ายกว่านี้ไหมสำหรับเรา?
มาดูวงจรชีวิตของธุรกรรมใน Hyperledger Fabric กันดีกว่า เพื่อทำความเข้าใจว่าอะไรต้องใช้เวลาและเกี่ยวข้องกับพารามิเตอร์การสร้างบล็อกอย่างไร
นำมาจากที่นี่:
(1) ลูกค้าสร้างธุรกรรม ส่งไปยังเพื่อนที่ได้รับการรับรอง ส่วนหลังจำลองธุรกรรม (ใช้การเปลี่ยนแปลงที่ทำโดยรหัสลูกโซ่กับสถานะปัจจุบัน แต่ไม่ได้ผูกมัดกับบัญชีแยกประเภท) และรับ RWSet - ชื่อคีย์ เวอร์ชัน และ ค่าที่นำมาจากคอลเลกชันใน CouchDB (2) ผู้รับรองส่ง RWSet ที่ลงนามแล้วกลับไปยังไคลเอนต์ (3) ลูกค้าตรวจสอบลายเซ็นของเพียร์ที่จำเป็นทั้งหมด (ผู้รับรอง) จากนั้นส่งธุรกรรมไปยังการสั่งซื้อ บริการหรือส่งโดยไม่มีการตรวจสอบ (การตรวจสอบจะยังคงเกิดขึ้นในภายหลัง) บริการสั่งซื้อจะสร้างบล็อกและ (4) ส่งกลับไปยังเพื่อนทั้งหมด ไม่ใช่แค่ผู้รับรองเท่านั้น เพื่อนจะตรวจสอบว่าเวอร์ชันของคีย์ในชุดการอ่านตรงกับเวอร์ชันในฐานข้อมูล ลายเซ็นของผู้รับรองทั้งหมด และสุดท้ายก็คอมมิตบล็อก
แต่นั่นไม่ใช่ทั้งหมด เบื้องหลังคำว่า "ผู้สั่งซื้อสร้างบล็อก" ไม่เพียงซ่อนการเรียงลำดับธุรกรรมเท่านั้น แต่ยังรวมถึงคำขอเครือข่าย 3 รายการติดต่อกันจากผู้นำถึงผู้ติดตามและด้านหลัง: ผู้นำเพิ่มข้อความลงในบันทึก ส่งไปยังผู้ติดตาม ส่วนหลังเพิ่มใน บันทึกของพวกเขา ส่งการยืนยันการจำลองแบบที่สำเร็จไปยังผู้นำ ผู้นำส่งข้อความ ส่งการยืนยันการคอมมิตไปยังผู้ติดตาม ผู้ติดตามคอมมิต ยิ่งขนาดและเวลาที่บล็อกเล็กลง บริการสั่งซื้อจะต้องสร้างความเห็นพ้องต้องกันบ่อยขึ้นเท่านั้น. Hyperledger Fabric มีพารามิเตอร์การสร้างบล็อกสองตัว: BatchTimeout - เวลาในการสร้างบล็อก และ BatchSize - ขนาดบล็อก (จำนวนธุรกรรมและขนาดของบล็อกในหน่วยไบต์) ทันทีที่พารามิเตอร์ตัวใดตัวหนึ่งถึงขีดจำกัด จะมีการออกบล็อกใหม่ ยิ่งโหนดผู้เรียงลำดับมากเท่าไร การดำเนินการนี้ก็จะยิ่งนานขึ้นเท่านั้น ดังนั้น คุณต้องเพิ่ม BatchTimeout และ BatchSize แต่เนื่องจาก RWSets เป็นเวอร์ชัน ยิ่งเราสร้างบล็อกให้ใหญ่ขึ้น ความน่าจะเป็นของข้อขัดแย้ง MVCC ก็จะยิ่งสูงขึ้นเท่านั้น นอกจากนี้ เมื่อ BatchTimeout เพิ่มขึ้น UX ก็จะลดลงอย่างมาก สำหรับฉันดูเหมือนว่าสมเหตุสมผลและชัดเจนถึงแผนการต่อไปนี้ในการแก้ไขปัญหาเหล่านี้
วิธีหลีกเลี่ยงการรอสรุปบล็อกและไม่พลาดสถานะธุรกรรม
ยิ่งเวลาก่อตัวและขนาดบล็อกนานเท่าใด ปริมาณงานของบล็อกเชนก็จะยิ่งสูงขึ้นเท่านั้น สิ่งใดสิ่งหนึ่งไม่ได้ติดตามโดยตรงจากอีกสิ่งหนึ่ง แต่ควรจำไว้ว่าการสร้างฉันทามติใน RAFT ต้องการคำขอเครือข่ายสามคำขอจากผู้นำไปยังผู้ติดตามและด้านหลัง ยิ่งโหนดสั่งซื้อมากเท่าไรก็ยิ่งใช้เวลานานขึ้นเท่านั้น ยิ่งขนาดและเวลาในการสร้างบล็อกเล็กลง การโต้ตอบดังกล่าวก็จะยิ่งมากขึ้นเท่านั้น จะเพิ่มเวลาการก่อตัวและขนาดบล็อกโดยไม่เพิ่มเวลาตอบสนองของระบบสำหรับผู้ใช้ปลายทางได้อย่างไร
ขั้นแรก คุณต้องแก้ไขข้อขัดแย้ง MVCC ที่เกิดจากขนาดบล็อกใหญ่ ซึ่งอาจรวมถึง RWSets ที่แตกต่างกันในเวอร์ชันเดียวกัน เห็นได้ชัดว่าในฝั่งไคลเอ็นต์ (ในส่วนที่เกี่ยวข้องกับเครือข่ายบล็อกเชน นี่อาจเป็นแบ็กเอนด์ และฉันหมายความตามนั้น) ตัวจัดการข้อขัดแย้ง MVCCซึ่งสามารถเป็นได้ทั้งบริการแยกต่างหากหรือตัวตกแต่งปกติบนการโทรที่เริ่มต้นธุรกรรมด้วยตรรกะการลองใหม่
การลองใหม่สามารถนำมาใช้โดยใช้กลยุทธ์แบบเอ็กซ์โพเนนเชียล แต่เวลาแฝงก็จะลดลงแบบทวีคูณเช่นกัน ดังนั้นคุณควรใช้การลองใหม่แบบสุ่มภายในขีดจำกัดเล็กๆ บางอย่างหรือแบบคงที่ พร้อมจับตาดูการชนที่อาจเกิดขึ้นได้ในรุ่นแรก
ขั้นตอนต่อไปคือการทำให้ไคลเอ็นต์โต้ตอบกับระบบแบบอะซิงโครนัสเพื่อไม่ให้รอเป็นเวลา 15, 30 หรือ 10000000 วินาที ซึ่งเราจะตั้งค่าเป็น BatchTimeout แต่ในขณะเดียวกัน จำเป็นต้องรักษาความสามารถในการตรวจสอบให้แน่ใจว่าการเปลี่ยนแปลงที่เริ่มต้นโดยธุรกรรมนั้นได้รับการบันทึก / ไม่ได้บันทึกในบล็อกเชน
สามารถใช้ฐานข้อมูลเพื่อจัดเก็บสถานะของธุรกรรมได้ ตัวเลือกที่ง่ายที่สุดคือ CouchDB เนื่องจากใช้งานง่าย ฐานข้อมูลมี UI พร้อมใช้งาน REST API และคุณสามารถตั้งค่าการจำลองและการแบ่งส่วนได้อย่างง่ายดาย คุณสามารถสร้างคอลเลกชันแยกต่างหากในอินสแตนซ์ CouchDB เดียวกับที่ Fabric ใช้เพื่อจัดเก็บสถานะโลกได้ เราจำเป็นต้องจัดเก็บเอกสารประเภทนี้
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}เอกสารนี้ถูกเขียนลงในฐานข้อมูลก่อนที่จะส่งธุรกรรมไปยังเพียร์ รหัสเอนทิตีจะถูกส่งกลับไปยังผู้ใช้ (รหัสเดียวกันจะถูกใช้เป็นคีย์) หากนี่คือการดำเนินการสร้าง จากนั้นฟิลด์สถานะ, TxID และข้อผิดพลาดจะถูก อัปเดตเมื่อได้รับข้อมูลที่เกี่ยวข้องจากเพื่อน
ในรูปแบบนี้ ผู้ใช้ไม่รอให้บล็อกก่อตัวในที่สุด โดยดูวงล้อหมุนบนหน้าจอเป็นเวลา 10 วินาที เขาได้รับการตอบสนองทันทีจากระบบและทำงานต่อไป
เราเลือก BoltDB เพื่อจัดเก็บสถานะธุรกรรมเนื่องจากเราจำเป็นต้องประหยัดหน่วยความจำและไม่ต้องการเสียเวลาในการโต้ตอบกับเครือข่ายกับเซิร์ฟเวอร์ฐานข้อมูลแบบสแตนด์อโลน โดยเฉพาะอย่างยิ่งเมื่อมีการโต้ตอบนี้เกิดขึ้นโดยใช้โปรโตคอลข้อความธรรมดา อย่างไรก็ตาม ไม่ว่าคุณจะใช้ CouchDB เพื่อนำโครงร่างที่อธิบายไว้ข้างต้นไปใช้หรือเพียงเพื่อจัดเก็บสถานะโลก ไม่ว่าในกรณีใดก็ตาม การเพิ่มประสิทธิภาพวิธีการจัดเก็บข้อมูลใน CouchDB ก็สมเหตุสมผล ตามค่าเริ่มต้น ใน CouchDB ขนาดของโหนด b-tree คือ 1279 ไบต์ ซึ่งเล็กกว่าขนาดเซกเตอร์บนดิสก์มาก ซึ่งหมายความว่าทั้งการอ่านและการปรับสมดุลแผนผังต้นไม้จะต้องมีการเข้าถึงดิสก์ทางกายภาพมากขึ้น ขนาดที่เหมาะสมที่สุดเป็นไปตามมาตรฐาน และมีขนาด 4 กิโลไบต์ สำหรับการเพิ่มประสิทธิภาพ เราต้องตั้งค่าพารามิเตอร์ btree_chunk_size เท่ากับ 4096 ในไฟล์คอนฟิกูเรชัน CouchDB สำหรับ BoltDB การแทรกแซงด้วยตนเองดังกล่าว .
แรงดันย้อนกลับ: กลยุทธ์บัฟเฟอร์
แต่อาจมีข้อความมากมาย มากกว่าที่ระบบจะสามารถรองรับได้ การแบ่งปันทรัพยากรกับบริการอื่นๆ มากมายนอกเหนือจากที่แสดงในแผนภาพ - และทั้งหมดนี้ควรจะทำงานได้อย่างไร้ที่ติแม้แต่บนเครื่องที่รัน Intellij Idea เป็นเรื่องที่น่าเบื่ออย่างยิ่ง
ปัญหาของปริมาณงานที่แตกต่างกันของระบบการสื่อสาร ผู้ผลิตและผู้บริโภค ได้รับการแก้ไขด้วยวิธีที่ต่างกัน มาดูกันว่าเราสามารถทำอะไรได้บ้าง
ลดลง: เราสามารถอ้างได้ว่าสามารถประมวลผลธุรกรรมได้สูงสุด X รายการใน T วินาที คำขอทั้งหมดที่เกินขีดจำกัดนี้จะถูกยกเลิก มันค่อนข้างง่าย แต่คุณก็ลืม UX ไปได้
การควบคุม: ผู้บริโภคต้องมีอินเทอร์เฟซบางอย่างซึ่งเขาสามารถควบคุม tps ของผู้ผลิตได้ ทั้งนี้ขึ้นอยู่กับโหลด ไม่เลว แต่มันกำหนดภาระผูกพันให้กับผู้พัฒนาโหลดไคลเอนต์เพื่อใช้อินเทอร์เฟซนี้ สำหรับเรา สิ่งนี้เป็นสิ่งที่ยอมรับไม่ได้ เนื่องจากบล็อกเชนในอนาคตจะถูกรวมเข้ากับระบบที่มีอยู่ยาวนานจำนวนมาก
บัฟเฟอร์: แทนที่จะพยายามต้านทานสตรีมข้อมูลอินพุต เราสามารถบัฟเฟอร์สตรีมนี้และประมวลผลด้วยความเร็วที่ต้องการ แน่นอนว่านี่เป็นทางออกที่ดีที่สุดหากเราต้องการมอบประสบการณ์ที่ดีแก่ผู้ใช้ เราใช้บัฟเฟอร์โดยใช้คิวใน RabbitMQ
มีการเพิ่มการกระทำใหม่สองประการในโครงการ: (1) หลังจากได้รับคำขอ API ข้อความจะถูกจัดคิวด้วยพารามิเตอร์ที่จำเป็นในการเรียกธุรกรรม และลูกค้าได้รับข้อความว่าธุรกรรมได้รับการยอมรับจากระบบแล้ว ( 2) แบ็กเอนด์อ่านข้อมูลด้วยความเร็วที่ระบุในการกำหนดค่าจากคิว เริ่มต้นธุรกรรมและอัพเดตข้อมูลในที่จัดเก็บสถานะ
ตอนนี้คุณสามารถเพิ่มเวลาในการสร้างและความจุของบล็อกได้มากเท่าที่คุณต้องการ โดยซ่อนความล่าช้าไม่ให้ผู้ใช้เห็น
เครื่องมืออื่นๆ
ไม่มีการพูดถึง chaincode ที่นี่ เพราะโดยปกติแล้วไม่มีอะไรจะเพิ่มประสิทธิภาพในนั้น รหัสลูกโซ่ควรเรียบง่ายและปลอดภัยที่สุดเท่าที่จะเป็นไปได้ นั่นคือทั้งหมดที่จำเป็น เฟรมเวิร์กช่วยเราได้มากในการเขียนเชนโค้ดอย่างง่ายดายและปลอดภัย จาก S7 Techlab และเครื่องวิเคราะห์แบบคงที่ .
นอกจากนี้ ทีมของเรากำลังพัฒนาชุดยูทิลิตี้เพื่อให้การทำงานกับ Fabric ง่ายและสนุกสนาน: , ยูทิลิตี้สำหรับ (เพิ่ม/ลบองค์กร, โหนด RAFT), ยูทิลิตี้สำหรับ . หากคุณต้องการมีส่วนร่วมยินดีต้อนรับ
ข้อสรุป
แนวทางนี้ทำให้ง่ายต่อการแทนที่ Hyperledger Fabric ด้วย Quorum เครือข่าย Ethereum ส่วนตัวอื่นๆ (PoA หรือแม้แต่ PoW) ลดปริมาณงานจริงลงอย่างมาก แต่ในขณะเดียวกันก็รักษา UX ตามปกติ (ทั้งสำหรับผู้ใช้ในเบราว์เซอร์และจากด้านข้างของระบบรวม ). เมื่อแทนที่ Fabric ด้วย Ethereum ในโครงร่าง เฉพาะตรรกะของบริการลองใหม่ / เครื่องมือตกแต่งเท่านั้นที่จำเป็นต้องเปลี่ยนจากการจัดการข้อขัดแย้ง MVCC ไปเป็นการเพิ่มและการส่งอะตอมมิกแบบ nonce ใหม่ การบัฟเฟอร์และการจัดเก็บสถานะทำให้สามารถแยกเวลาตอบสนองออกจากเวลาการสร้างบล็อกได้ ตอนนี้คุณสามารถเพิ่มโหนดคำสั่งซื้อได้หลายพันรายการ และไม่ต้องกลัวว่าบล็อกจะเกิดขึ้นบ่อยเกินไปและโหลดบริการสั่งซื้อ
โดยทั่วไปนี่คือทั้งหมดที่ฉันต้องการแบ่งปัน ฉันจะดีใจถ้ามันช่วยใครบางคนในการทำงานของพวกเขา
ที่มา: will.com