ในโลกของบล็อกเชน เรามักจะได้ยินคำหนึ่งอยู่บ่อยครั้ง: "การต่อต้านการเซ็นเซอร์" (Censorship Resistance)
หลายคนเมื่อได้ยินครั้งแรก อาจรู้สึกว่ามันฟังดูเหมือนสโลแกนที่เอนเอียงไปทางการเมือง หรือแม้กระทั่งมีกลิ่นอายของลัทธิอนาธิปไตย แต่สำหรับ Ethereum ซึ่งเป็นเครือข่ายชำระบัญชีที่เปิดให้ผู้ใช้ทั่วโลกเข้าถึงได้ การต่อต้านการเซ็นเซอร์ประการแรกไม่ใช่จุดยืนทางการเมือง แต่เป็นความสามารถทางเทคนิคที่จับต้องได้อย่างเป็นรูปธรรม
ลองจินตนาการว่า คุณได้ทำการส่งธุรกรรมหนึ่งรายการจากกระเป๋าเงิน imToken
ลายเซ็นถูกต้อง ยอดเงินในบัญชีเพียงพอ ค่าแก๊ส (Gas) ก็ไม่ได้สูงจนเกินไป แต่ธุรกรรมนั้นกลับไม่ถูกบันทึกลงในบล็อกสักที สถานะในกระเป๋าเงินยังคงค้างอยู่ที่ "Pending" (รอดำเนินการ) ในขณะเดียวกัน ธุรกรรมอื่น ๆ ที่มีค่าธรรมเนียมใกล้เคียงกันหรือ甚至ต่ำกว่ากลับถูกบันทึกลงในบล็อกอย่างต่อเนื่อง
ณ จุดนี้ ปัญหาจึงเปลี่ยนไปเป็นว่า ท้ายที่สุดแล้ว ใครกันแน่ที่มีสิทธิ์ตัดสินใจว่าธุรกรรมหนึ่ง ๆ จะสามารถเข้าไปอยู่ในบล็อกได้หรือไม่? เพราะ หากท้ายที่สุดแล้ว Ethereum ยังคงต้องพึ่งพาผู้มีส่วนร่วมแบบรวมศูนย์เพียงไม่กี่รายในการตัดสินใจว่าธุรกรรมใดสามารถขึ้นบล็อกได้ เช่นนั้นแล้ว มันก็ไม่ต่างไปจากระบบการเงินแบบดั้งเดิมเลย
ด้วยเหตุนี้ ในช่วงไม่กี่ปีที่ผ่านมา Ethereum จึงกำลังสำรวจกลไกการต่อต้านการเซ็นเซอร์มากมาย เช่น FOCIL, FairFIL เป็นต้น ซึ่งก็คือความพยายามที่จะตอบคำถามที่ดูเหมือนง่าย แต่จริง ๆ แล้วซับซ้อนมาก: จะทำอย่างไรจึงจะรับประกันได้ว่าธุรกรรมใด ๆ ที่เป็นไปตามกฎของโปรโตคอล จะมีโอกาสอย่างเป็นธรรมในการเข้าไปอยู่ในบล็อก?
หนึ่ง: แท้จริงแล้ว "การเซ็นเซอร์" เกิดขึ้นจากที่ไหน?
เพื่อให้เข้าใจว่าเหตุใด Ethereum จึงต้องมีกลไกเหล่านี้ ก่อนอื่นเราต้องทำความเข้าใจก่อนว่า หลังจากที่ธุรกรรมหนึ่งถูกส่งออกจากกระเป๋าเงินไปแล้ว มันต้องผ่านอะไรมาบ้าง
เมื่อผู้ใช้ลงนามและส่งธุรกรรมภายในกระเป๋าเงิน ธุรกรรมนั้นมักจะถูกส่งเข้าไปยัง พูลธุรกรรมสาธารณะของ Ethereum หรือที่เรียกว่า Mempool (หน่วยความจำพูล) ซึ่งเปรียบเสมือนโซนรอ ที่รวบรวมธุรกรรมจำนวนมากที่ยังไม่ถูกบันทึกลงในบล็อก
แต่การเข้าไปอยู่ในโซนรอ ไม่ได้หมายความว่าธุรกรรมได้ถูกบันทึกลงในบล็อกแล้ว ยัง需要有ผู้ที่คอยคัดเลือกธุรกรรมเหล่านั้น กำหนดลำดับก่อนหลัง ประกอบกันเป็นบล็อกที่สมบูรณ์ แล้วส่งต่อไปให้เครือข่ายทำการยืนยัน
ปัญหาก็เกิดขึ้นในขั้นตอนนี้เอง
หลังจากที่ Ethereum อัปเกรดไปใช้กลไก PoS (Proof of Stake — การพิสูจน์ส่วนได้ส่วนเสีย) เพื่อป้องกันไม่ให้พูลการstakingขนาดใหญ่ใช้ประโยชน์จาก MEV (Maximal Extractable Value — มูลค่าที่สกัดได้สูงสุด) ในการผูกขาดทางเศรษฐกิจ Ethereum จึงได้นำระบบ PBS (Proposer-Builder Separation — การแยกบทบาทระหว่างผู้เสนอและผู้สร้าง) มาใช้ ในสถาปัตยกรรมนี้ ขั้นตอนการประมวลผลธุรกรรม Ethereum แต่ละรายการ จะถูกแบ่งออกเป็นสองบทบาทที่รับผิดชอบ:
- Builder (ผู้สร้างบล็อก): มีหน้าที่รวบรวมธุรกรรม จัดลำดับธุรกรรม ค้นหาโอกาสในการเก็งกำไรและการชำระบัญชี และสร้างบล็อกที่ให้ผลตอบแทนสูงที่สุดเท่าที่จะเป็นไปได้;
- Proposer (ผู้เสนอบล็อก): มีหน้าที่เลือกหนึ่งในบล็อกที่ผู้สร้างเสนอมา และส่งต่อไปยังเครือข่าย;
การแบ่งหน้าที่แบบนี้มีข้อดีในทางปฏิบัติอย่างมาก
เป็นที่ทราบกันดีว่า ในช่วงไม่กี่ปีมานี้ กลยุทธ์ MEV มีความซับซ้อนมากขึ้นเรื่อย ๆ หากกำหนดให้ผู้ตรวจสอบความถูกต้อง (Validator) ทั่วไปทุกคนต้องจัดเรียงลำดับธุรกรรมและปรับปรุงบล็อกให้เหมาะสมด้วยตนเอง นั่นย่อมทำให้ผู้ให้บริการรายใหญ่ที่มีเงินทุน ข้อมูล และความสามารถทางเทคนิคมากกว่ากลายเป็นฝ่ายได้เปรียบอย่างเห็นได้ชัด
ดังนั้น การมอบหมายงานสร้างบล็อกที่ซับซ้อนให้กับ Builder มืออาชีพ แม้โหนดผู้ตรวจสอบความถูกต้องทั่วไปจะไม่มีความสามารถในการเก็งกำไรขั้นสูง พวกเขาก็ยังสามารถมีส่วนร่วมในการเสนอบล็อกและได้รับผลตอบแทนที่เหมาะสม ซึ่งช่วยลดผลกระทบของ MEV ที่มีต่อการกระจายอำนาจของการstaking ได้
เพียงแต่มันก็ได้นำมาซึ่งผลข้างเคียงอีกประการหนึ่งโดยไม่ได้ตั้งใจ นั่นคือ การรวมศูนย์ของอำนาจในการสร้างบล็อกมากเกินไป ตัวอย่างเช่น ในปัจจุบัน บล็อกของ Ethereum มากกว่า 90% ทั่วทั้งเครือข่าย ถูกผลิตโดย Builder มืออาชีพเพียงไม่กี่รายเท่านั้น และเนื่องจาก Builder เหล่านี้มักจะมีพื้นฐานการดำเนินงานขององค์กรที่ชัดเจน จึง极易ตกอยู่ภายใต้แรงกดดันจากการปฏิบัติตามกฎหมายและข้อบังคับของประเทศหรือภูมิภาคใดภูมิภาคหนึ่ง (เช่น รายชื่อการคว่ำบาตรของ OFAC) ดังนั้น ในทางปฏิบัติแล้ว สิ่งนี้ได้ก่อให้เกิดความเสี่ยงจากการรวมศูนย์แล้ว
และด้วยเหตุนี้เอง หาก Builder รายใหญ่เพียงไม่กี่รายนี้เลือกที่จะกรองธุรกรรมบางอย่างที่เกี่ยวข้องกับสัญญาที่ละเอียดอ่อน (เช่น Tornado Cash) หรือที่อยู่เฉพาะบางแห่งออกไป ธุรกรรมเหล่านั้นก็จะตกอยู่ในสถานการณ์ที่ยากจะถูกบรรจุเข้าบล็อกเป็นเวลานาน หรือ甚至ต้องเผชิญกับความเสี่ยงที่จะถูก "แบนโดยไม่เป็นทางการ"
กล่าวโดยสรุป ในมุมมองของผู้ใช้ทั่วไป Ethereum คือเครือข่ายเปิดที่ใครก็สามารถเชื่อมต่อ โอนเงิน และเรียกใช้สัญญาอัจฉริยะได้ แต่ในมุมมองของการทำงานของโปรโตคอล การส่งธุรกรรมเป็นเพียงขั้นตอนแรกเท่านั้น การที่ธุรกรรมจะสามารถมีผลจริงได้หรือไม่ ยังขึ้นอยู่กับว่าธุรกรรมนั้นจะถูกเลือก จัดเรียงลำดับ และถูกบันทึกลงในบล็อกโดยผู้สร้างบล็อกรายใดรายหนึ่งหรือไม่
ดังนั้น "การต่อต้านการเซ็นเซอร์" ที่ Ethereum พูดถึงนั้น ไม่ใช่เพียงแนวคิดกว้าง ๆ ที่เกี่ยวข้องกับการเมือง กฎระเบียบ หรือการคว่ำบาตรเท่านั้น แต่ประการแรกมันเป็นปัญหาทางเทคนิคที่เฉพาะเจาะจงมาก:
เมื่อธุรกรรมหนึ่งเป็นไปตามกฎของโปรโตคอล เครือข่ายจะสามารถรับประกันได้หรือไม่ว่าธุรกรรมนั้นจะได้รับโอกาสในการเข้าสู่บล็อกภายในระยะเวลาที่เหมาะสม?
สอง: จาก FOCIL ถึง FairFIL: Ethereum จำกัดผู้สร้างบล็อกอย่างไร
จริง ๆ แล้ว เมื่อพูดมาถึงจุดนี้ ปัญหาค่อนข้างชัดเจนแล้ว Builder สามารถเพิ่มประสิทธิภาพในการสร้างบล็อกได้ แต่หากสิทธิ์ในการรวมธุรกรรมตกอยู่ในมือของ Builder เพียงไม่กี่รายเป็นเวลานาน Ethereum ก็จะเกิดความเสี่ยงจากการผูกขาดแบบรวมศูนย์ขึ้นมาใหม่ได้อีกครั้ง
ด้วยเหตุนี้ นักวิจัยของ Ethereum จึงได้เสนอแนวคิด Inclusion Lists หรือที่เรามักเรียกว่า "รายการรวมธุรกรรม"
ชื่อนี้อาจฟังดูเป็นนามธรรมไปสักหน่อย แต่หลักการหลักของมันไม่ได้ซับซ้อนเลย——Builder ยังคงเป็นผู้สร้างบล็อก แต่ไม่สามารถตัดสินใจชะตากรรมของธุรกรรมทั้งหมดได้เพียงลำพัง โหนดผู้ตรวจสอบความถูกต้องที่เข้าร่วมในการ staking ของ Ethereum ตามปกติก็ต้องมีอำนาจบางส่วนไว้ด้วย เพื่อให้พวกเขาสามารถระบุรายการธุรกรรมที่จำเป็นต้องได้รับการจัดการได้
ยกตัวอย่างเช่น สถานีรถโดยสารประจำทาง เราสามารถเปรียบเทียบแต่ละบล็อกเสมือนเป็นรถโดยสารโดยสารคันหนึ่งที่มีจำนวนที่นั่งจำกัด
Builder เป็นผู้ตัดสินใจว่าผู้โดยสารส่วนใหญ่จะต่อแถวอย่างไร นั่งตรงตำแหน่งไหน เพื่อเพิ่มผลตอบแทนของรถโดยสารทั้งคันผ่านการจัดการที่มีประสิทธิภาพมากขึ้น แต่โหนดผู้ตรวจสอบความถูกต้องก็สามารถยื่น "รายชื่อผู้โดยสารที่ต้องขึ้นรถ" ได้เช่นกัน ตราบใดที่ธุรกรรมในรายชื่อยังคงมีผล ยินดีจ่ายค่าธรรมเนียมที่สมเหตุสมผล และบล็อกยังมีพื้นที่เพียงพอ Builder ก็ไม่สามารถปฏิเสธธุรกรรมเหล่านั้นได้เพียงเพราะความชอบส่วนตัวของตัวเองอยู่เรื่อยไป
อย่างไรก็ตาม ปัญหาที่ว่าบุคคลใดจะเป็นคนสร้างรายการรวมธุรกรรมหนึ่ง ๆ และจะทำอย่างไรหากมีผู้จงใจละเว้นธุรกรรมบางรายการ ก็ยังคงเป็นปัญหาสองข้อที่ต้องได้รับการแก้ไขต่อไป
FOCIL และ FairFIL คือสิ่งที่ดำเนินไปตามแนวทางทั้งสองนี้
1. FOCIL: ไม่อนุญาตให้ Proposer เพียงคนเดียวเป็นผู้ออกรายการรวมอีกต่อไป
FOCIL (Fork-Choice Enforced Inclusion Lists) ได้โอนอำนาจในการตัดสินใจว่าธุรกรรมใดบ้างที่ต้องถูกรวมเข้าบล็อก จากผู้เสนอเพียงรายเดียวไปยัง "คณะกรรมการโหนดผู้ตรวจสอบความถูกต้อง" ที่ประกอบด้วยหลายฝ่าย
ในแต่ละรอบการผลิตบล็อก เครือข่ายจะสุ่มเลือกกลุ่มโหนดผู้ตรวจสอบความถูกต้องจำนวนหนึ่งเพื่อจัดตั้งเป็นคณะกรรมการชั่วคราว สมาชิกแต่ละคนในคณะกรรมการจะสังเกต Mempool ของเครือข่ายอย่างอิสระ และแต่ละคนจะส่งรายการรวมธุรกรรมในท้องถิ่นของตนเอง
ซึ่งหมายความว่า ถึงแม้ Builder และ Proposer 99% ทั่วทั้งเครือข่ายจะพยายามเซ็นเซอร์ธุรกรรมใดธุรกรรมหนึ่ง ตราบใดที่มีโหนดที่ซื่อสัตย์เพียง 1 โหนดในคณะกรรมการที่นำธุรกรรมนั้นใส่ในรายการ ธุรกรรมนั้นก็มีโอกาสที่จะได้รับการคุ้มครองโดยข้อบังคับของโปรโตคอล ผู้ที่ต้องการแยกธุรกรรมนั้นออกไปต่อไป จะไม่ใช่แค่การมีอิทธิพลต่อบุคคลเพียงคนเดียวอีกต่อไป แต่จำเป็นต้องเลี่ยงผู้มีส่วนร่วมอิสระหลายรายพร้อมกัน
ดังนั้น ข้อดีของมันคือ ไม่จำเป็นต้องเชื่อใจว่าทุกคนในคณะกรรมการจะวางตัวเป็นกลาง
แต่การมีเพียงรายการอย่างเดียวยังไม่พอ หาก Builder ได้รับรายการแล้ว แต่ยังคงเลือกที่จะไม่ปฏิบัติตาม รายการรวมธุรกรรมก็จะกลายเป็นเพียงคำแนะนำที่ไร้ผลบังคับ
ดังนั้น FOCIL จึงได้เพิ่มการออกแบบชั้นที่สอง โดยนำกลไกการเลือก Fork (Fork-Choice Rule) มาใช้เป็นข้อบังคับที่เข้มงวด ทำให้โหนดที่รับผิดชอบการลงคะแนนตรวจสอบทั่วทั้งเครือข่ายตรวจสอบบล็อกที่ Builder ส่งมาอย่างเคร่งครัด ทันทีที่ตรวจพบว่า Builder กล้าที่จะละเมิดรายการรวมที่คณะกรรมการรวบรวมไว้ ทั้งเครือข่ายจะปฏิเสธการลงคะแนนให้กับบล็อกนั้นโดยตรง
ซึ่งหมายความว่าบล็อกที่ละเมิดกฎจะถูกตัดสินโดยโปรโตคอลทันทีว่าเป็นบล็อกที่ไม่ถูกต้อง และ Builder จะต้องแบกรับต้นทุนความล้มเหลวในการผลิตบล็อกที่มหาศาล
2. FairFIL: ไม่เพียงแต่ต้องอุดช่องโหว่ แต่ยังต้องทำให้การละเว้นธุรกรรมสามารถตรวจสอบได้
หากกล่าวว่า FOCIL คือการห้ามการเซ็นเซอร์อย่างเด็ดขาดผ่านกฎเกณฑ์ที่เป็นเอกฉันท์ (Consensus) แล้ว FairFIL (Fair Forward Inclusion Lists) และกลไกความรับผิดชอบก็คือการทำให้การเซ็นเซอร์มีต้นทุนที่สูงมากและไม่สามารถยั่งยืนได้จากมุมมองทางเศรษฐศาสตร์
พูดง่าย ๆ คือ มันเสนอข้อกำหนดที่ก้าวหน้ายิ่งขึ้นไปอีก เช่น สาเหตุที่ธุรกรรมหนึ่งไม่ถูกบันทึกลงในบล็อก ควรจะทิ้งบันทึกที่สามารถตรวจสอบได้ต่อสาธารณะให้มากที่สุด
ในการทำงานของเครือข่ายจริง Builder อาจต้องมีช่วงเวลาปรับตัวที่สั้นมากเพื่อปรับปรุงการจัดลำดับธุรกรรมและการเก็งกำไรจาก MEV ให้ดีขึ้น FairFIL อนุญาตให้ Builder ปรับเปลี่ยนได้อย่างยืดหยุ่นภายใต้ข้อจำกัดเฉพาะ แต่หาก Builder พยายามที่จะสานต่อการเซ็นเซอร์บางอย่างต่อไปยังบล็อกถัดไป โปรโตคอลจะเริ่มดำเนินกระบวนการสอบสวนทันที
ตรรกะโดยคร่าวของมัน สามารถแบ่งออกเป็นสามขั้นตอนเพื่อทำความเข้าใจได้
- ประการแรก โปรโตคอลจะกำหนดชุดกฎอ้างอิงที่เปิดเผยและตรวจสอบได้ เพื่อใช้ตัดสินว่าธุรกรรมใดบ้างในพูลธุรกรรมสาธารณะ ที่ภายใต้สถานการณ์ปกติมีคุณสมบัติที่จะเข้าสู่บล็อกปัจจุบัน หากธุรกรรมบางรายการที่มีคุณสมบัติตามกฎอ้างอิงที่จะเข้าสู่บล็อกได้ แต่สุดท้ายไม่ได้รับการจัดการ Builder จะต้องนำธุรกรรมเหล่านั้นไประบุไว้อย่างเปิดเผยใน FairFIL;
- ต่อจากนั้น ผู้ตรวจสอบความถูกต้องจะตรวจสอบว่ารายการนี้ครบถ้วนหรือไม่ หาก Builder ละเว้นธุรกรรมที่มีคุณสมบัติครบถ้วน แต่กลับไม่เขียนมันลงในรายการ พฤติกรรมนี้อาจถูกตรวจพบ และส่งผลต่อการที่โหนดผู้ตรวจสอบความถูกต้องจะสนับสนุนบล็อกนั้นหรือไม่;
- สุดท้าย ธุรกรรมที่ถูกต้องซึ่งเข้าสู่ FairFIL จะกลายเป็นภารกิจที่ต้องได้รับการจัดการเป็นลำดับแรกในบล็อกถัดไป Builder รายถัดไปยังคงสามารถจัดวางตำแหน่งเฉพาะของธุรกรรมเหล่านั้นในบล็อกได้ แต่ไม่สามารถแสร้งทำเป็นไม่เห็นมันอีกต่อไป;
หากธุรกรรมหนึ่งถูกละเว้นอย่างต่อเนื่อง บล็อกที่เกี่ยวข้องอาจสูญเสียการสนับสนุนจากผู้ตรวจสอบความถูกต้อง และ Builder อาจสูญเสียผลตอบแทนของทั้งบล็อกได้เช่นกัน
กล่าวอีกนัยหนึ่ง "ความรับผิดชอบ" ที่ FairFIL เน้นย้ำนั้น แท้จริงแล้วคือการนำบทลงโทษทางเศรษฐกิจแบบเป็นขั้นบันไดมาใช้ ทำให้ Builder ที่เซ็นเซอร์ธุรกรรมอย่างต่อเนื่องต้องเสี่ยงต่อการถูกยึดรางวัลทั้งบล็อก หรือ甚至面临การถูกยึดเงินมัดจำจากการ staking
นี่เป็นทิศทางที่กลไกการต่อต้านการเซ็นเซอร์ของ Ethereum ค่อย ๆ พัฒนาไปอย่างลึกซึ้ง ซึ่งมีจุดมุ่งหมายเพื่อสร้างข้อจำกัดที่สมจริงยิ่งขึ้น แม้ผู้มีส่วนร่วมเพียงไม่กี่รายจะมีความตั้งใจที่จะเซ็นเซอร์ ก็ยากที่จะควบคุมประตูทางเข้าของธุรกรรมได้ในระยะยาว แม้จะมีผู้จงใจละเว้นธุรกรรม ก็จำเป็นต้องทิ้งร่องรอยไว้ และต้องจ่ายต้นทุนที่สูงขึ้นเรื่อย ๆ สำหรับการเซ็นเซอร์อย่างต่อเนื่อง
สาม: สิ่งนี้หมายความว่าอย่างไรสำหรับผู้ใช้ทั่วไป?
สำหรับผู้ใช้
