การต่อสู้ต้านการเซ็นเซอร์ชิปของ Ethereum: BRAID vs. FOCIL - ใครจะเป็นผู้ชนะ

กลาง9/5/2024, 1:04:43 AM
บทความนี้ให้การวิเคราะห์ลึกซึ้งเกี่ยวกับปัญหาการเซ็นเซอร์สถานการณ์การทำธุรกรรมบน Ethereum blockchain มันสำรวจความเสี่ยงของการมีร่วมกันระหว่างผู้เสนอและผู้ก่อสร้างและผลกระทบของการต้านทานการเซ็นเซอร์บล็อกเชน นอกจากนี้ยังมีการแนะนำอย่างละเอียดเกี่ยวกับสองตัวเลือกต้านการเซ็นเซอร์ FOCIL และ BRAID โดยพิจารณากลไกของพวกเขา ข้อดี ความท้าทาย และข้อเสนอแนะจากชุมชน

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

หนึ่งในค่านิยมหลักของบล็อกเชนคือการต่อต้านการเซ็นเซอร์ซึ่งหมายความว่าการทําธุรกรรมสามารถดําเนินการได้โดยปราศจากการแทรกแซงจากหน่วยงานกลาง เมื่อผู้เสนอควบคุมธุรกรรมที่รวมอยู่ในบล็อกคุณลักษณะนี้จะถูกคุกคามกระทบต่อความเป็นธรรมและความโปร่งใส นอกจากนี้อํานาจนี้สามารถใช้ประโยชน์เพื่อจัดการกับลําดับของธุรกรรมในบล็อกซึ่งนําไปสู่ผลประโยชน์ทางเศรษฐกิจเพิ่มเติมและเพิ่มประเด็นที่เกี่ยวข้องกับ Miner Extractable Value (MEV)

Existing censorship-resistant solutions

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

นอกจาก FOCIL ชุมชนยังได้พูดถึงโครงการ Multiple Concurrent Proposers (MCP) โดยเฉพาะ แนวคิดนี้ถูกเสนอครั้งแรกโดยแม็กซ์ เรสนิกในความหลากหลาย กลไกซึ่งมีจุดมุ่งหมายเพื่อกระจายอํานาจโดยการแนะนําผู้เสนอบล็อกแบบขนานหลายตัวลดความสามารถของโหนดเดียวในการเซ็นเซอร์ธุรกรรม ในกลไก Multiplicity ผู้ตรวจสอบความถูกต้องแต่ละคนจะเลือกส่วนหนึ่งของธุรกรรมจาก mempool ของตนเองเพื่อสร้าง "แพ็คเกจธุรกรรมพิเศษ" ผู้ตรวจสอบเหล่านี้ลงนามในแพ็คเกจธุรกรรมที่เลือกและส่งไปยังผู้เสนอรอบปัจจุบัน ผู้เสนอจะต้องมีอย่างน้อย 2 ใน 3 ของแพคเกจการทําธุรกรรมเหล่านี้ในบล็อกที่พวกเขาเสนอเพื่อให้ถือว่าถูกต้อง กลไกนี้ช่วยให้มั่นใจได้ว่าผู้เสนอไม่สามารถตัดสินใจเนื้อหาของบล็อกได้เพียงฝ่ายเดียวซึ่งจะช่วยลดความเป็นไปได้ของการเซ็นเซอร์ เพื่อจูงใจให้ผู้เสนอธุรกรรมรวมธุรกรรมอย่างเป็นธรรมกลไกนี้ใช้กฎ "เคล็ดลับแบบมีเงื่อนไข" โดยเฉพาะผู้เสนอที่รวมธุรกรรมเท่านั้นที่ได้รับค่าธรรมเนียมการทําธุรกรรม ค่าธรรมเนียมการทําธุรกรรมจะไม่มอบให้กับผู้เสนอรายแรกโดยอัตโนมัติเพื่อรวมธุรกรรม แต่จะแจกจ่ายให้กับผู้เสนอทุกรายที่รวมธุรกรรมตามเงื่อนไขเฉพาะ สิ่งนี้จะเพิ่มค่าใช้จ่ายในการเซ็นเซอร์เนื่องจากการติดสินบนผู้เสนอทั้งหมดที่รวมธุรกรรมเป็นสิ่งจําเป็น

ถักเปีย: การใช้งาน MCP ที่ได้รับการปรับปรุง

จากแนวคิด Multiplicity Max Resnick ได้แนะนํา BRAID ซึ่งเป็นการใช้งาน MCP ที่ซับซ้อนและประณีตยิ่งขึ้น แม็กซ์นําเสนอ BRAID ในงานสัมมนา "DeFi in the MEV Era" ที่จัดขึ้นโดย Paradigm BRAID บรรลุ MCP โดยอนุญาตให้ผู้เสนอหลายรายเสนอบล็อกบนโซ่คู่ขนานที่แตกต่างกันและใช้กลไกฉันทามติการซิงโครไนซ์เพื่อรักษาความสอดคล้องระหว่างโซ่เหล่านี้ แต่ละห่วงโซ่มีผู้เสนอของตัวเองและผู้เสนอทั้งหมดปล่อยบล็อกของพวกเขาพร้อมกันภายในช่องเดียวกัน เลเยอร์การดําเนินการ Ethereum aggreGates บล็อกที่สร้างขึ้นโดยโซ่ย่อยทั้งหมดภายในสล็อตนั้นสร้างบล็อกการดําเนินการ จากนั้นจะขจัดข้อมูลซ้ําซ้อนจัดเรียงและดําเนินการธุรกรรมเหล่านี้ตามกฎที่กําหนดไว้ล่วงหน้าลดความสามารถของเอนทิตีเดียวในการจัดการบันทึกธุรกรรม

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

ปัญหากับกลไก BRAID

Jonahb จากทีม Blockchain Capital ชี้ให้เห็นว่า ปัญหาด้วยกลไก BRAID: รูปแบบ "ตัวช่วยเงื่อนไข" กำหนดข้อกำหนดเกี่ยวกับความสามารถในการเล่นของผู้ใช้ รูปแบบนี้เป็นกลยุทธ์การกำหนดราคาแบบไดนามิกที่ต้องการผู้ใช้จะต้องให้ความสามารถในการเล่นเพื่อให้มั่นใจว่าการซ่อนอยู่ระหว่างการทำรายการจะได้รับการตรวจสอบโดยไม่มีการเซ็นเซอร์สตริง ในการส่งธุรกรรมผู้ใช้ต้องตั้งค่าค่า Tip 2 ค่า (T และ t) มูลค่า Tip ที่จ่ายจริงขึ้นอยู่กับจำนวนผู้เสนอข้อเสนอที่รวมถึงการทำธุรกรรม

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

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

เพื่อแก้ไขปัญหานี้ โจนาบเสนอสองวิธี

  • หลักฐานสภาพคล่องหลังรัฐ: ผู้ใช้แสดงหลักฐานในขณะที่ส่งธุรกรรมซึ่งระบุว่าพวกเขาจะมีสภาพคล่องเพียงพอที่จะจ่าย T หลังจากดําเนินการธุรกรรม (เช่นผู้ใช้จะมีสภาพคล่อง $ 1M หลังการทําธุรกรรม) วิธีนี้ช่วยให้ผู้ใช้สามารถดําเนินการต่อได้แม้ว่าพวกเขาจะมีเงินไม่เพียงพอที่จะจ่าย T ก่อนการทําธุรกรรม ความท้าทายของแนวทางนี้คือผู้เสนอจําเป็นต้องทราบสถานะสุดท้ายของธุรกรรมก่อนดําเนินการ อย่างไรก็ตามธุรกรรมทางการเงินจํานวนมากเกี่ยวข้องกับสถานะที่ใช้ร่วมกัน (เช่นธุรกรรมหลายรายการที่มีผลต่อยอดคงเหลือในบัญชีเดียวกัน) ทําให้ผู้เสนอยากที่จะกําหนดสถานะหลังการทําธุรกรรมอย่างถูกต้องก่อนที่การสั่งซื้อธุรกรรมจะเสร็จสิ้น วิธีการนี้ต้องการหลักฐานที่กําหนดเองสําหรับธุรกรรมแต่ละประเภททําให้ใช้งานได้จริงน้อยลง
  • ประกันการเซ็นเซอร์: นำเสนอผู้ให้บริการประกันการเซ็นเซอร์บุคคลที่สาม (ผู้ให้บริการ CI) เพื่อรับประกัน T ของผู้ใช้ ผู้ใช้จ่ายเบี้ยประกันภัย rT โดยที่ r ขึ้นอยู่กับความน่าจะเป็นของการทำธุรกรรมถูกเซ็นเซอร์ วิธีนี้จะลดความจำเป็นในการเตรียมเงินสดจำนวนมากในทันทีและสามารถแจ้งเตือนผู้ใช้ในกรณีที่ T ของพวกเขาต่ำเกินไปและเสี่ยงต่อการถูกเซ็นเซอร์ อย่างไรก็ตาม การสร้างตลาดระหว่างผู้ใช้และผู้ให้บริการ CI ต้องใช้เวลา

ความคิดของชุมชนเกี่ยวกับ FOCIL vs. BRAID

นักพัฒนา Ethereum client PrysmTerence หมายเหตุข้อดีที่สำคัญของ BRAID คือ ไม่จำเป็นต้องมีผู้ร่วมสนับสนุนเพิ่มเติม การออกแบบ Inclusion List (IL) ซึ่งรวมถึง FOCIL ต้องการผู้ร่วมสนับสนุนเพิ่มเติม ซึ่งเพิ่มข้อจำกัดในเวลาภายใน Ethereum slots เช่น เวลาสำหรับการส่ง IL การอัปเดตการประมูล และการตรวจสอบ IL จาก validators อย่างไรก็ตาม FOCIL มีความง่ายและยืดหยุ่นกว่าในการนำมาใช้เมื่อเทียบกับ BRAID

นักวิจัยด้านพาราดิกมแดน โรบินสัน ต้องขอบคุณการออกแบบของ BRAID สำหรับการจัดลำดับธุรกรรมที่ไม่ได้ถูกกำหนดโดยผู้นำเดียว (ผู้เสนอ), ทำให้ลดความเสี่ยงจาก MEV ได้อย่างมีประสิทธิภาพ นอกจากนี้ยังมีกลไกการให้เครื่องหมายทักทายแบบเงื่อนไขของ BRAID ที่ส่งเสริมพฤติกรรมที่ไม่สามารถตรวจสอบได้ ซึ่งไม่มีใน FOCIL

นักพัฒนาDev ชอบโดยเชื่อถือ FOCIL มากกว่า MCP เนื่องจากเชื่อว่า FOCIL มีความต้านทานต่อการเซ็นเซอร์ชั่นที่แข็งแกร่งกว่าและง่ายต่อการใช้งานมากขึ้น เขายังแนะนำบางปรับปรุงเพื่อทำให้ FOCIL ง่ายต่อการใช้งาน

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

คำแถลง

  1. บทความนี้ถูกคัดลอกมาจาก[ChainFeeds การวิจัย], หัวข้อเดิมคือ “Ethereum's road to censorship resistance: Who is better, BRAID or FOCIL?”, ลิขสิทธิ์เป็นของผู้เขียนเดิม [0XNATALIE], หากคุณมีคำประทับใจใด ๆ เกี่ยวกับการเผยแพร่ใหม่ ๆ กรุณาติดต่อ ทีมเรียนรู้เกต , ทีมจะดำเนินการให้เร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง

  2. ข้อปฏิเสธ: มุมมองและความเห็นที่แสดงในบทความนี้เป็นเพียงมุมมองส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นที่ปรึกษาการลงทุนใด ๆ

  3. เวอร์ชันภาษาอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn ซึ่งไม่ได้กล่าวถึงGate.io, บทความที่แปลอาจไม่นำเสนอหรือเผยแพร่โดยละเมิดลิขสิทธิ์หรือเอกสารสิทธิ์

การต่อสู้ต้านการเซ็นเซอร์ชิปของ Ethereum: BRAID vs. FOCIL - ใครจะเป็นผู้ชนะ

กลาง9/5/2024, 1:04:43 AM
บทความนี้ให้การวิเคราะห์ลึกซึ้งเกี่ยวกับปัญหาการเซ็นเซอร์สถานการณ์การทำธุรกรรมบน Ethereum blockchain มันสำรวจความเสี่ยงของการมีร่วมกันระหว่างผู้เสนอและผู้ก่อสร้างและผลกระทบของการต้านทานการเซ็นเซอร์บล็อกเชน นอกจากนี้ยังมีการแนะนำอย่างละเอียดเกี่ยวกับสองตัวเลือกต้านการเซ็นเซอร์ FOCIL และ BRAID โดยพิจารณากลไกของพวกเขา ข้อดี ความท้าทาย และข้อเสนอแนะจากชุมชน

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

หนึ่งในค่านิยมหลักของบล็อกเชนคือการต่อต้านการเซ็นเซอร์ซึ่งหมายความว่าการทําธุรกรรมสามารถดําเนินการได้โดยปราศจากการแทรกแซงจากหน่วยงานกลาง เมื่อผู้เสนอควบคุมธุรกรรมที่รวมอยู่ในบล็อกคุณลักษณะนี้จะถูกคุกคามกระทบต่อความเป็นธรรมและความโปร่งใส นอกจากนี้อํานาจนี้สามารถใช้ประโยชน์เพื่อจัดการกับลําดับของธุรกรรมในบล็อกซึ่งนําไปสู่ผลประโยชน์ทางเศรษฐกิจเพิ่มเติมและเพิ่มประเด็นที่เกี่ยวข้องกับ Miner Extractable Value (MEV)

Existing censorship-resistant solutions

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

นอกจาก FOCIL ชุมชนยังได้พูดถึงโครงการ Multiple Concurrent Proposers (MCP) โดยเฉพาะ แนวคิดนี้ถูกเสนอครั้งแรกโดยแม็กซ์ เรสนิกในความหลากหลาย กลไกซึ่งมีจุดมุ่งหมายเพื่อกระจายอํานาจโดยการแนะนําผู้เสนอบล็อกแบบขนานหลายตัวลดความสามารถของโหนดเดียวในการเซ็นเซอร์ธุรกรรม ในกลไก Multiplicity ผู้ตรวจสอบความถูกต้องแต่ละคนจะเลือกส่วนหนึ่งของธุรกรรมจาก mempool ของตนเองเพื่อสร้าง "แพ็คเกจธุรกรรมพิเศษ" ผู้ตรวจสอบเหล่านี้ลงนามในแพ็คเกจธุรกรรมที่เลือกและส่งไปยังผู้เสนอรอบปัจจุบัน ผู้เสนอจะต้องมีอย่างน้อย 2 ใน 3 ของแพคเกจการทําธุรกรรมเหล่านี้ในบล็อกที่พวกเขาเสนอเพื่อให้ถือว่าถูกต้อง กลไกนี้ช่วยให้มั่นใจได้ว่าผู้เสนอไม่สามารถตัดสินใจเนื้อหาของบล็อกได้เพียงฝ่ายเดียวซึ่งจะช่วยลดความเป็นไปได้ของการเซ็นเซอร์ เพื่อจูงใจให้ผู้เสนอธุรกรรมรวมธุรกรรมอย่างเป็นธรรมกลไกนี้ใช้กฎ "เคล็ดลับแบบมีเงื่อนไข" โดยเฉพาะผู้เสนอที่รวมธุรกรรมเท่านั้นที่ได้รับค่าธรรมเนียมการทําธุรกรรม ค่าธรรมเนียมการทําธุรกรรมจะไม่มอบให้กับผู้เสนอรายแรกโดยอัตโนมัติเพื่อรวมธุรกรรม แต่จะแจกจ่ายให้กับผู้เสนอทุกรายที่รวมธุรกรรมตามเงื่อนไขเฉพาะ สิ่งนี้จะเพิ่มค่าใช้จ่ายในการเซ็นเซอร์เนื่องจากการติดสินบนผู้เสนอทั้งหมดที่รวมธุรกรรมเป็นสิ่งจําเป็น

ถักเปีย: การใช้งาน MCP ที่ได้รับการปรับปรุง

จากแนวคิด Multiplicity Max Resnick ได้แนะนํา BRAID ซึ่งเป็นการใช้งาน MCP ที่ซับซ้อนและประณีตยิ่งขึ้น แม็กซ์นําเสนอ BRAID ในงานสัมมนา "DeFi in the MEV Era" ที่จัดขึ้นโดย Paradigm BRAID บรรลุ MCP โดยอนุญาตให้ผู้เสนอหลายรายเสนอบล็อกบนโซ่คู่ขนานที่แตกต่างกันและใช้กลไกฉันทามติการซิงโครไนซ์เพื่อรักษาความสอดคล้องระหว่างโซ่เหล่านี้ แต่ละห่วงโซ่มีผู้เสนอของตัวเองและผู้เสนอทั้งหมดปล่อยบล็อกของพวกเขาพร้อมกันภายในช่องเดียวกัน เลเยอร์การดําเนินการ Ethereum aggreGates บล็อกที่สร้างขึ้นโดยโซ่ย่อยทั้งหมดภายในสล็อตนั้นสร้างบล็อกการดําเนินการ จากนั้นจะขจัดข้อมูลซ้ําซ้อนจัดเรียงและดําเนินการธุรกรรมเหล่านี้ตามกฎที่กําหนดไว้ล่วงหน้าลดความสามารถของเอนทิตีเดียวในการจัดการบันทึกธุรกรรม

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

ปัญหากับกลไก BRAID

Jonahb จากทีม Blockchain Capital ชี้ให้เห็นว่า ปัญหาด้วยกลไก BRAID: รูปแบบ "ตัวช่วยเงื่อนไข" กำหนดข้อกำหนดเกี่ยวกับความสามารถในการเล่นของผู้ใช้ รูปแบบนี้เป็นกลยุทธ์การกำหนดราคาแบบไดนามิกที่ต้องการผู้ใช้จะต้องให้ความสามารถในการเล่นเพื่อให้มั่นใจว่าการซ่อนอยู่ระหว่างการทำรายการจะได้รับการตรวจสอบโดยไม่มีการเซ็นเซอร์สตริง ในการส่งธุรกรรมผู้ใช้ต้องตั้งค่าค่า Tip 2 ค่า (T และ t) มูลค่า Tip ที่จ่ายจริงขึ้นอยู่กับจำนวนผู้เสนอข้อเสนอที่รวมถึงการทำธุรกรรม

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

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

เพื่อแก้ไขปัญหานี้ โจนาบเสนอสองวิธี

  • หลักฐานสภาพคล่องหลังรัฐ: ผู้ใช้แสดงหลักฐานในขณะที่ส่งธุรกรรมซึ่งระบุว่าพวกเขาจะมีสภาพคล่องเพียงพอที่จะจ่าย T หลังจากดําเนินการธุรกรรม (เช่นผู้ใช้จะมีสภาพคล่อง $ 1M หลังการทําธุรกรรม) วิธีนี้ช่วยให้ผู้ใช้สามารถดําเนินการต่อได้แม้ว่าพวกเขาจะมีเงินไม่เพียงพอที่จะจ่าย T ก่อนการทําธุรกรรม ความท้าทายของแนวทางนี้คือผู้เสนอจําเป็นต้องทราบสถานะสุดท้ายของธุรกรรมก่อนดําเนินการ อย่างไรก็ตามธุรกรรมทางการเงินจํานวนมากเกี่ยวข้องกับสถานะที่ใช้ร่วมกัน (เช่นธุรกรรมหลายรายการที่มีผลต่อยอดคงเหลือในบัญชีเดียวกัน) ทําให้ผู้เสนอยากที่จะกําหนดสถานะหลังการทําธุรกรรมอย่างถูกต้องก่อนที่การสั่งซื้อธุรกรรมจะเสร็จสิ้น วิธีการนี้ต้องการหลักฐานที่กําหนดเองสําหรับธุรกรรมแต่ละประเภททําให้ใช้งานได้จริงน้อยลง
  • ประกันการเซ็นเซอร์: นำเสนอผู้ให้บริการประกันการเซ็นเซอร์บุคคลที่สาม (ผู้ให้บริการ CI) เพื่อรับประกัน T ของผู้ใช้ ผู้ใช้จ่ายเบี้ยประกันภัย rT โดยที่ r ขึ้นอยู่กับความน่าจะเป็นของการทำธุรกรรมถูกเซ็นเซอร์ วิธีนี้จะลดความจำเป็นในการเตรียมเงินสดจำนวนมากในทันทีและสามารถแจ้งเตือนผู้ใช้ในกรณีที่ T ของพวกเขาต่ำเกินไปและเสี่ยงต่อการถูกเซ็นเซอร์ อย่างไรก็ตาม การสร้างตลาดระหว่างผู้ใช้และผู้ให้บริการ CI ต้องใช้เวลา

ความคิดของชุมชนเกี่ยวกับ FOCIL vs. BRAID

นักพัฒนา Ethereum client PrysmTerence หมายเหตุข้อดีที่สำคัญของ BRAID คือ ไม่จำเป็นต้องมีผู้ร่วมสนับสนุนเพิ่มเติม การออกแบบ Inclusion List (IL) ซึ่งรวมถึง FOCIL ต้องการผู้ร่วมสนับสนุนเพิ่มเติม ซึ่งเพิ่มข้อจำกัดในเวลาภายใน Ethereum slots เช่น เวลาสำหรับการส่ง IL การอัปเดตการประมูล และการตรวจสอบ IL จาก validators อย่างไรก็ตาม FOCIL มีความง่ายและยืดหยุ่นกว่าในการนำมาใช้เมื่อเทียบกับ BRAID

นักวิจัยด้านพาราดิกมแดน โรบินสัน ต้องขอบคุณการออกแบบของ BRAID สำหรับการจัดลำดับธุรกรรมที่ไม่ได้ถูกกำหนดโดยผู้นำเดียว (ผู้เสนอ), ทำให้ลดความเสี่ยงจาก MEV ได้อย่างมีประสิทธิภาพ นอกจากนี้ยังมีกลไกการให้เครื่องหมายทักทายแบบเงื่อนไขของ BRAID ที่ส่งเสริมพฤติกรรมที่ไม่สามารถตรวจสอบได้ ซึ่งไม่มีใน FOCIL

นักพัฒนาDev ชอบโดยเชื่อถือ FOCIL มากกว่า MCP เนื่องจากเชื่อว่า FOCIL มีความต้านทานต่อการเซ็นเซอร์ชั่นที่แข็งแกร่งกว่าและง่ายต่อการใช้งานมากขึ้น เขายังแนะนำบางปรับปรุงเพื่อทำให้ FOCIL ง่ายต่อการใช้งาน

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

คำแถลง

  1. บทความนี้ถูกคัดลอกมาจาก[ChainFeeds การวิจัย], หัวข้อเดิมคือ “Ethereum's road to censorship resistance: Who is better, BRAID or FOCIL?”, ลิขสิทธิ์เป็นของผู้เขียนเดิม [0XNATALIE], หากคุณมีคำประทับใจใด ๆ เกี่ยวกับการเผยแพร่ใหม่ ๆ กรุณาติดต่อ ทีมเรียนรู้เกต , ทีมจะดำเนินการให้เร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง

  2. ข้อปฏิเสธ: มุมมองและความเห็นที่แสดงในบทความนี้เป็นเพียงมุมมองส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นที่ปรึกษาการลงทุนใด ๆ

  3. เวอร์ชันภาษาอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn ซึ่งไม่ได้กล่าวถึงGate.io, บทความที่แปลอาจไม่นำเสนอหรือเผยแพร่โดยละเมิดลิขสิทธิ์หรือเอกสารสิทธิ์

Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!