#ReadingCrypto EP.01 The Meaning of Decentralization | ความหมายของการกระจายศูนย์

ผู้เขียน: วิทาลิก บิวเทอริน (Vitalik Buterin) บทความต้นฉบับตีพิมพ์เมื่อวันที่ 6 กุมภาพันธ์ 2017 อ่านความเรียงต้นฉบับภาษาอังกฤษได้ที่นี่ อ่าน Translator’s Note ได้ที่นี่

[ความเรียงภาคภาษาไทยนี้เป็นส่วนหนึ่งของซีรีส์ #ReadingCrypto ซีรีส์แปลความเรียงเท็กซ์หลัก (canonical text) ภาษาอังกฤษที่เกี่ยวกับปรัญชา, แนวคิด, วัฒนธรรม และประวัติศาสตร์ของคริปโต, Web 3.0 และอินเตอร์เน็ต]

“การกระจายศูนย์” (Decentralization) เป็นคำที่ถูกใช้บ่อยที่สุดคำหนึ่งในพื้นที่ของเศรษฐศาสตร์คริปโต (cryptoeconomics) และมักจะถูกมองว่าเป็นเหตุผลของการมีอยู่ของบล็อกเชนอย่างแท้จริง แต่กระนั้น มันก็เป็นคำที่ถูกนิยามไว้ได้แย่มากที่สุดคำหนึ่งเช่นกัน งานวิจัยกว่าหลายพันชั่วโมง และพลังการประมวลผลแฮช (hashpower) มูลค่ากว่าหลายพันล้านเหรียญฯ ถูกลงไปกับจุดประสงค์หนึ่งเดียวของการทำให้เกิดการกระจายศูนย์ อีกทั้งยังต้องบำรุงรักษา และพัฒนาให้ดียิ่งขึ้นไป และเมื่อใดที่การถกเถียงเริ่มดุเดือด มันเป็นเรื่องแสนจะปกติที่ฝ่ายเสนอของโพรโทคอลนั้นๆ (หรือส่วนขยายของโพรโทคอล) จะอ้างว่าข้อเสนอของเหล่าฝ่ายค้านทั้งหลายต่าง “รวมศูนย์” (centralized) ซึ่งถือว่าเป็นข้อโต้แย้งไม้ตายที่ล้มคู่แข่งได้อย่างชะงัด

อย่างไรก็ดี มักจะเกิดความสับสนบ่อยๆ ว่าแท้จริงแล้ว คำนี้หมายความว่าอย่างไรกันแน่ ขอยกกรณีตัวอย่าง ลองพิจารณาแผนภาพแสนไร้ประโยชน์แต่พบเห็นได้ทั่วไป อย่างแผนภาพด้านล่างนี้:

รูป.1 (ก) รวมศูนย์ (ข) กระจายศูนย์ (ค) เครือข่ายแบบกระจาย

คราวนี้ ลองมาดูสองคำตอบในกระทู้ “อะไรคือความแตกต่างระหว่างการกระจายและการกระจายศูนย์” บน Quora กัน คำตอบแรกหยิบยกแผนภาพด้านบนราวกับเป็นนกแก้วนกขุนทอง ส่วนคำตอบที่สองก็แสดงความเห็นที่แตกต่างไปอย่างสิ้นเชิงว่า “การกระจายหมายถึงว่า ไม่ใช่ทุกธุรกรรมจะถูกประมลผลในแห่งเดียวกัน” แต่ “การกระจายศูนย์หมายถึงว่า ไม่มีผู้ใดผู้หนึ่งที่จะมีอำนาจสามารถควบคุมการประมวลผลได้” ในขณะเดียวกัน คำตอบอันดับหนึ่งในกลุ่มอีเธอเรียมบน Stack ก็ตอบด้วยแผนภาพที่มีลักษณะคล้ายคลึงกับแผนภาพด้านบนมาก แต่ด้วยตำแหน่งของคำว่า “การกระจายศูนย์” และ “การกระจาย” นั้นสลับที่กัน! ชัดเจนแล้วว่า คำชี้แจงมันอยู่ในลำดับ!

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

• การกระจาย(หรือรวม)ศูนย์เชิงสถาปัตยกรรม - ระบบประกอบขึ้นจากคอมพิวเตอร์ที่จับต้องได้จำนวนกี่เครื่อง? ระบบยังสามารถดำเนินการต่อได้แม้คอมพิวเตอร์เหล่านั้นเกิดเสียหายในคราวเดียวสูงสุดกี่เครื่อง?

• การกระจาย(หรือรวม)ศูนย์เชิงการเมือง - มีคนกี่คนหรือองค์กรกี่กลุ่มที่มีอำนาจในการควบคุมคอมพิวเตอร์ที่ระบบกำลังวิ่งอยู่ทั้งหมดได้อย่างเบ็ดเสร็จ?

• การกระจาย(หรือรวม)ศูนย์เชิงตรรกะ - อินเตอร์เฟสและโครงสร้างข้อมูลที่ระบบนำเสนอและดำเนินการอยู่ ดูแล้วเหมือนเป็นวัตถุที่เป็นมวลก้อนใหญ่ชิ้นเดียว หรือฝูงอสัณฐานไร้รูปร่างตายตัวมากกว่ากัน? วิธีการค้นหาคำตอบด้วยตัวเองแบบง่ายๆ ก็คือ ถ้าคุณผ่าระบบออกเป็นสองส่วน โดยรวมทั้งฝั่งผู้ให้บริการและผู้ใช้งานแล้ว ทั้งสองส่วนจะสามารถทำงานได้ตามปกติในฐานะหน่วยย่อยอิสระได้หรือไม่?

เราสามารถลองนำมิติทั้งสามมาใส่ลงในแผนภาพนี้ได้:

พึงสังเกตว่า หลายข้อในชาร์ตนี้ถูกวางอย่างหยาบๆ และสร้างข้อโต้แย้งได้อีกมาก แต่มาลองดูตามไปทีละอัน:

• บริษัทแบบดั้งเดิมมีการเมืองแบบรวมศูนย์ (ซีอีโอหนึ่งคน) ใช้สถาปัตยกรรมแบบรวมศูนย์ (สำนักงานใหญ่หนึ่งแห่ง) และดำเนินการด้วยตรรกะแบบรวมศูนย์ (ไม่สามารถแบ่งครึ่งบริษัทได้)

• ระบบประมวลกฎหมายพึ่งพิงคณะร่างกฎหมายแบบรวมศูนย์ ในขณะที่ระบบกฎหมายจารีตประเพณีสร้างขึ้นจากการตัดสินใจที่ผ่านมาของผู้พิพากษาแต่ละคน ระบบประมวลกฎหมายยังพอจะใช้สถาปัตยกรรมแบบกระจายศูนย์ เนื่องจากมีศาลหลายแห่ง ที่ถึงแม้จะให้น้ำหนักกับดุลยพินิจของเจ้าหน้าที่ แต่ระบบกฎหมายจารีตประเพณีก็ยังให้น้ำหนักมากกว่า อย่างไรก็ดี ทั้งสองต่างมีตรรกะที่รวมศูนย์ (“กฎหมายก็คือกฎ”)

• ภาษามีตรรกะแบบกระจายศูนย์ ภาษาอังกฤษที่อลิซใช้สื่อสารกับบ็อบ ไม่จำเป็นต้องสอดคล้องกับภาษาอังกฤษที่ชาร์ลีใช้สื่อสารกับเดวิดเลย ภาษาไม่ต้องมีโครงสร้างแบบรวมศูนย์เพื่อที่จะให้มันคงอยู่ได้ และกฎไวยากรณ์ภาษาอังกฤษไม่ได้ถูกสร้างหรือถูกกำหนดโดยใครคนใดคนหนึ่ง (แม้ว่าภาษาเอสเปรันโตเดิมทีจะถูกคิดค้นโดยลุดวิก ซาเมนฮอฟ (Ludwig Zamenhof) แต่ปัจจุบันมันก็ทำงานเหมือนกับภาษาที่ใช้กันอยู่ในสมัยนี้มากกว่า ซึ่งค่อยๆ วิวัฒน์โดยปราศจากผู้คุมกฎ)

• บิตทอร์เรนต์ทำงานแบบกระจายศูนย์ในเชิงตรรกะเช่นเดียวกับภาษาอังกฤษ เครือข่ายการส่งเนื้อหา (content delivery network) ก็คล้ายกัน แต่ว่ามันถูกควบคุมโดยบริษัทใดบริษัทหนึ่ง

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

บ่อยครั้งที่เวลาใครพูดถึงคุณงามความดีของบล็อกเชน พวกเขามักจะเอ่ยถึงประโยชน์ด้านความสะดวกของการมี “ฐานข้อมูลกลางเพียงแห่งเดียว” การรวมศูนย์เช่นนี้ถือเป็นการรวมศูนย์เชิงตรรกะ และการรวมศูนย์ประเภทนี้อาจจะกล่าวได้ในหลายๆ กรณีว่าเป็นเรื่องที่ดี (แต่ฮวน เบเนต์ (Juan Benet) จาก IPFS จะผลักดันให้เกิดการกระจายศูนย์เชิงตรรกะในทุกๆ ที่ที่เป็นไปได้ เพราะระบบที่ใช้ตรรกะแบบกระจายศูนย์มักจะเอาชีวิตรอดจากการแบ่งส่วนเครือข่ายได้อย่างเก่งกาจ และทำงานได้ดีในพื้นที่ที่มีการเชื่อมต่อที่ไม่ค่อยดี เป็นต้น ลองอ่านต่อได้ในบทความนี้บน Scuttlebot ที่พูดถึงการสนับสนุนตรรกะแบบกระจายศูนย์อย่างตรงไปตรงมา)

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

การรวมศูนย์เชิงตรรกะจะทำให้การกระจายศูนย์เชิงสถาปัตยกรรมเกิดได้ยากขึ้น แต่ก็ไม่ใช่ว่าจะเป็นเรื่องที่ไปไม่ได้ ดูอย่างเครือข่ายฉันทามติ (consensus) แบบกระจายศูนย์ที่แสดงให้เห็นแล้วว่ามันใช้การได้จริง แต่อาจจะยากกว่าการบำรุงรักษาบิตทอร์เรนต์ นอกจากนั้น การรวมศูนย์เชิงตรรกะจะทำให้การกระจายศูนย์เชิงการเมืองเกิดขึ้นได้ยากขึ้น มันยากที่จะคลี่คลายปัญหาของข้อขัดแย้งอันรุนแรงภายในระบบที่ใช้ตรรกะเชิงรวมศูนย์ ด้วยเพียงแค่ “การที่ทุกคนตกลงยอมให้แต่ละคนทำตามที่ตัวเองต้องการและเดินหน้ากันต่อไป”

คำถามต่อไปคือ ทำไมการกระจายศูนย์ถึงมีประโยชน์ตั้งแต่แรก? มีข้อโต้แย้งหลายๆ ข้อที่มักจะถูกยกขึ้นมา:

• ความทนทานต่อความผิดพลาด - ระบบแบบกระจายศูนย์มีแนวโน้มที่จะล้มเหลวโดยบังเอิญน้อยกว่า เพราะพวกมันพึ่งพาส่วนประกอบที่แยกส่วนกันซึ่งมีความไปได้ต่ำว่าจะล้มเหลว

• ความต้านทานต่อการถูกโจมตี - การโจมตี ทำลาย หรือแทรกแซงระบบกระจายศูนย์มีค่าใช้จ่ายที่แพงกว่ามาก เนื่องจากระบบเช่นนี้ไม่มีจุดเปราะบางที่สามารถโจมตีได้ด้วยค่าใช้จ่ายต่ำกว่าขนาดเศรษฐกิจโดยรวมของระบบทั้งหมดอย่างมีนัยยะ

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

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

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

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

บล็อกเชนในรูปแบบปัจจุบัน [ปี 2017] สามารถป้องกันความล้มเหลวพร้อมกันได้หรือไม่? ก็อาจจะไม่ได้ทุกครั้ง ลองพิจารณาสถานการณ์ต่อไปนี้:

• โหนด (node) ทุกตัวในบล็อกเชนทำงานอยู่บนซอฟต์แวร์ไคลเอ็นต์ (software client) เดียวกัน และปรากฏว่าซอฟต์แวร์ไคลเอ็นต์ตัวนี้เกิดมีบั๊ก

• โหนดทุกตัวในบล็อกเชนทำงานอยู่บนซอฟต์แวร์ไคลเอ็นต์เดียวกัน และทีมนักพัฒนาซอฟต์แวร์นี้ ปรากฏว่าเป็นพวกสามานย์

• ทีมนักวิจัยที่ทำข้อเสนอการอัพเกรดของโพรโทคอล กลายเป็นพวกคนสามานย์

• ในบล็อกเชนแบบ Proof of Work (PoW) กว่า 70 เปอร์เซ็นต์ของนักขุดอยู่ในประเทศเดียวกัน และรัฐบาลของประเทศนั้นเกิดตัดสินใจที่จะยึดเหมืองขุดทั้งหมดด้วยเหตุผลทางความมั่นคงของชาติ

• ฮาร์ดแวร์สำหรับการขุดส่วนใหญ่ถูกสร้างโดยบริษัทเดียวกัน และบริษัทนี้ถูกติดสินบนหรือถูกจูงจมูกให้สร้างประตูหลังบ้านที่สามารถปิดฮาร์ดแวร์ได้ตามอำเภอใจ

• ในบล็อกเชนแบบ Proof of Stake (PoS) เหรียญกว่า 70 เปอร์เซ็นต์ถูก stake ไว้กับกระดานเทรดเพียงเจ้าเดียว

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

• มันสำคัญมากที่จะต้องมีการลงมือหลากหลายรูปแบบที่เพื่อให้เกิดการแข่งขัน

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

• ทีมนักพัฒนาหลักและทีมนักวิจัยควรจะเป็นทีมที่มาจาก

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

คราวนี้ เราลองมาดูในฝั่งของความต้านทานต่อการถูกโจมตีบ้าง ในโมเดลจำลองทางเศรษฐศาสตร์แบบเพียวๆ บางอัน คุณอาจจะเจอผลลัพธ์ว่าในบางครั้งการกระจายศูนย์ก็ไม่ได้มีผลอะไรเลย ถ้าคุณสร้างโพรโทคอลที่รับประกันว่าวาลิเดเตอร์ (validator) จะต้องสูญเสียเงินจำนวน 50 ล้านเหรียญฯ หากเกิดการโจมตี 51เปอร์เซ็นต์ (51% attack) (เช่น การยกเลิกยอดบัญชีที่ถูกบันทึกไปแล้ว (finality reversion)) ด้วยเหตุนี้ มันไม่ได้สลักสำคัญอะไรเลย ถ้าวาลิเดเตอร์ทั้งหลายจะถูกควบคุมโดยบริษัทแห่งเดียวหรือหนึ่งร้อยบริษัท เนื่องจากมาร์จิ้นความมั่นคงทางเศรษฐกิจจำนวน 50 ล้านเหรียญฯ ก็ยังเท่ากับมาร์จิ้นความมั่นคงทางเศรษฐกิจจำนวน 50 ล้านเหรียญฯ ความจริงแล้วเหตุผลทางทฤษฎีเกมเชิงลึก ว่าทำไมการรวมศูนย์นั้นอาจจะช่วยทำให้ความตระหนักรู้เกี่ยวกับความมั่นคงทางเศรษฐกิจให้เพิ่มสูงสุด (โมเดลการคัดเลือกธุรกรรมในบล็อกเชนที่มีอยู่ ณ ปัจจุบัน [ปี 2017] ได้สะท้อนถึงข้อมูลเชิงลึกนี้ เพราะการรวมธุรกรรมเข้าไปในบล็อกผ่านนักขุด/ผู้เสนอบล็อก แท้จริงแล้วเป็นเผด็จการที่มีการหมุนเวียนอย่างรวดเร็ว)

อย่างไรก็ตาม เมื่อคุณได้เปิดรับโมเดลเศรษฐกิจที่อุดมสมบูรณ์กว่า และโดยเฉพาะโมเดลที่ยอมรับว่ามีความเป็นไปได้ที่จะเกิดการบีบบังคับขู่เข็ญ (หรือสิ่งที่ร้ายแรงน้อยกว่านั้น เช่น การโจมตี DoS ที่พุ่งเป้าไปยังโหนด) การกระจายศูนย์จะมีความสำคัญมากยิ่งขึ้น ถ้าคุณเกิดขู่กรรโชกใครคนหนึ่งด้วยความตาย เงินจำนวน 50 ล้านเหรียญฯ จะหมดความหมายสำหรับพวกเขาในทันที แต่ถ้าเงินจำนวน 50 ล้านเหรียญฯ ถูกกระจายไปให้คนสิบคน คุณจะต้องขู่กรรโชกคนเพิ่มขึ้นเป็นสิบเท่าตัว และยังต้องลงมือข่มขู่ทุกคนพร้อมๆ กันอีกด้วย โดยทั่วไปแล้ว โลกสมัยใหม่ในหลายๆ ครั้งถูกนิยามลักษณะผ่านความไม่สมมาตรของการโจมตี/การป้องกัน ซึ่งมักจะเอื้อประโยชน์ต่อผู้โจมตี ยกตัวอย่างเช่น ตึกที่มีค่าใช้จ่ายในการก่อสร้างเป็นจำนวนเงิน 10 ล้านเหรียญฯ อาจจะใช้เงินน้อยกว่า 100,000 เหรียญฯ ในการทำลาย แต่ทั้งนี้การยกระดับ (leverage) ของผู้โจมตีมักจะเป็นแบบ sublinear เช่น ถ้าตึกแห่งหนึ่งใช้เงินจำนวน 10 ล้านเหรียญฯ ในการก่อสร้าง และใช้เงิน 100,000 เหรียญฯ ในการทำลาย ตึกที่ใช้เงินหนึ่งล้านเหรียญฯ ในการสร้าง ตามความจริงแล้วก็น่าจะใช้เงินประมาณ 30,000 เหรียญฯ ในการทำลาย ยิ่งจำนวนน้อยยิ่งให้อัตราส่วนที่ดี

แล้วการพินิจพิเคราะห์เช่นนี้จะนำไปสู่อะไร? ลำดับแรก มันให้ประโยชน์ฝั่ง Proof of Stake เหนือฝั่ง Proof of Work อย่างยิ่งยวด เพราะฮาร์ดแวร์คอมพิวเตอร์นั้นง่ายต่อการแกะรอย, ควบคุม, และโจมตี ส่วนเหรียญนั้น สามารถถูกเก็บซ่อนได้ง่ายกว่ามาก (นอกจากนี้ Proof of Stake ยังสามารถต่อต้านการโดนโจมตีได้อย่างแข็งแกร่งเพราะเหตุผลประการอื่นๆ ด้วย) ลำดับที่สอง มันเป็นเหตุผลของการสนับสนุนให้เกิดการกระจายตัวของทีมนักพัฒนาไปในวงกว้าง ซึ่งรวมไปถึงการกระจายตัวทางภูมิศาสตร์ ลำดับที่สาม มันเป็นการกล่าวอย่างกลายๆ ว่าทั้งโมเดลทางเศรษฐศาสตร์และโมเดลการต่อต้านความล้มเหลวจำเป็นต้องถูกนำมาพิจารณาระหว่างการออกแบบโพรโทคอลฉันทามติด้วย

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

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

ในกรณีโพรโทคอลบล็อกเชน การพินิจพิเคราะห์ทางคณิตศาสตร์และเศรษฐศาสตร์ที่อยู่เบื้องหลังเกราะกำบังของฉันทามติ มักจะพึ่งพาโมเดลตัวเลือกแบบไม่ร่วมมือกัน หรือการอนุมานว่าเกมประกอบไปด้วยผู้เล่นตัวเล็กหลายๆ คนที่ตัดสินใจด้วยตนเอง ถ้าเมื่อใดที่มีผู้เล่นคนไหนเกิดมีพลังการขุดมากกว่า ⅓ ในระบบ Proof of Work พวกเขาจะสามารถได้รับกำไรก้อนใหญ่มหาศาลผ่านการขุดแบบเห็นแก่ตัว แต่กระนั้น เราสามารถพูดได้อย่างเต็มปากเต็มคำหรือว่าโมเดลตัวเลือกแบบไม่ร่วมมือกันนั้นสามารถปฏิบัติได้จริง เมื่อเครือข่ายการขุดของบิตคอยน์กว่า 90 เปอร์เซ็นร่วมมือกันได้ดีในระดับที่สามารถโผล่มาที่งานสัมมนาเดียวกันได้อย่างพร้อมหน้าพร้อมตา?

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

แต่กระนั้นก็ดี ประเด็นนี้ได้แสดงให้เห็นความย้อนแยงในระดับพื้นฐาน ชุมชนหลายๆ แห่งรวมไปถึงอีเธอเรียม มักจะถูกชื่นชมว่ามีสปิริตที่แข็งแกร่ง และสามารถร่วมแรงร่วมใจกันพัฒนา, ปล่อย และเปิดใช้งาน hard fork ได้อย่างรวดเร็ว เพื่อแก้ปัญหาการปฏิเสธการให้บริการ (denial-of-service) ในโพรโทคอลภายในหกวัน แต่จะทำอย่างไรให้เราสามารถส่งเสริมและพัฒนาการร่วมมือในรูปแบบที่ดีงามเช่นนี้ แต่ในขณะเดียวกันป้องกัน “การร่วมมือที่เลวร้าย” ที่เกิดจากนักขุดพยายามจะเอาเปรียบคนอื่นๆ ผ่านการร่วมมือเพื่อโจมตีแบบ 51 เปอร์เซ็นต์?

ในการตอบคำถามนี้ มีสามทางด้วยกัน:

• ไม่ต้องสนใจที่จะหยุดยั้งการร่วมมือกันแบบที่ไม่เป็นที่ต้องการ แต่พยายามสร้างโพรโทคอลที่สามารถต่อต้านมันได้ดีกว่า

• พยายามหาสื่อที่ดีที่ทำให้เกิดการร่วมมือในระดับที่จะทำให้โพรโทคอลพัฒนาไปข้างหน้าไป แต่ไม่เพียงพอที่จะทำให้เกิดการโจมตีได้

• พยายามหาข้อแตกต่างระหว่างการร่วมมือที่มีประโยชน์และการร่วมมือที่เป็นอันตราย และทำข้อแรกให้ง่ายลง ทำข้อหลังให้ยากขึ้น

วิธีแรกเป็นส่วนประกอบขนาดใหญ่ของปรัญชาการออกแบบแคสเปอร์ (Casper) แต่กระนั้น โดยลำพังแค่ตัวมันเองนั้นไม่เพียงพอ เพราะการพึ่งพาเศรษฐศาสตร์เพียงอย่างเดียวไม่สามารถจัดการกับข้อกังวลอีกสองข้อเกี่ยวกับการกระจายศูนย์ได้ ส่วนข้อที่สองนั้นยากที่จะออกแบบและสร้างให้เป็นรูปธรรม โดยเฉพาะในระยะยาว แต่มันมักจะเกิดขึ้นด้วยความบังเอิญ ยกตัวอย่างเช่น ข้อเท็จจริงที่ว่านักพัฒนาหลักของบิตคอยน์มักจะพูดภาษาอังกฤษแต่เหล่านักขุดส่วนใหญ่พูดภาษาจีนถือได้ว่าเป็นความบังเอิญที่น่ายินดี เพราะมันได้ทำให้เกิดการปกครองโดยใช้ “ระบบสองสภา” (bicameral) ที่ทำให้การร่วมมือกันยากขึ้นไปอีก ซึ่งมีข้อดีข้างเคียงด้วยการลดความเสี่ยงของการเกิดความล้มเหลวพร้อมกัน เนื่องจากทั้งชุมชนที่ใช้ภาษาอังกฤษและชุมชนที่ใช้ภาษาจีนน่าจะมีการพูดคุยกันด้วยเหตุผล ซึ่งน่าจะเป็นบทสนทนาที่แยกวงกัน เนื่องจากระยะทางที่ห่างกันและความยากในการสื่อสาร เพราะฉะนั้นความเป็นไปที่คนทั้งสองกลุ่มจะทำผิดพลาดในเรื่องเดียวกันได้น้อยลง

ข้อที่สามนั้นเป็นความท้าทายในฝั่งสังคมเหนือสิ่งอื่นใด ทางออกในส่วนนี้อาจจะรวมไปถึง:

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

• สนับสนุนการสื่อสารระหว่าง “ฝั่งต่างๆ ภายในตลาด” ด้วยบริบทเดียวกัน เพื่อลดความเป็นไปได้ที่กลุ่มวาลิเดเตอร์, กลุ่มนักพัฒนา, หรือกลุ่มนักขุด จะเริ่มเห็นตัวเองเป็น “ชนชั้น” ซึ่งควรทำงานร่วมกันเพื่อปกป้องผลประโยชน์ของตัวเองจากชนชั้นอื่นๆ

• ออกแบบโพรโทคอลในรูปแบบที่จะลดแรงจูงใจสำหรับวาลิเดเตอร์/นักขุด ให้เข้าไปข้องแวะกับ “ความสัมพันธ์สุดพิเศษ” แบบหนึ่งต่อหนึ่ง หรือระบบเครือข่ายการถ่ายโอนข้อมูลแบบรวมศูนย์ และกลไกที่มีความคล้ายคลึงกับซุปเปอร์โพรโทรคอลยักษ์ใหญ่

• บรรทัดฐานที่ชัดเจนว่าคุณสมบัติพื้นฐานที่โพรโทคอลควรจะมีมีอะไรบ้าง และสิ่งที่ไม่ควรจะทำ หรืออย่างน้อยทำได้แค่ภายในสถานการณ์สุดโต่งไม่คาดฝัน

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

เกี่ยวกับผู้เขียน วิทาลิก บิวเทอริน (Vitalik Buterin) คือนักวิจัย โปรแกรมเมอร์ นักคิด นักเขียน และผู้ร่วมก่อตั้ง Bitcoin Magazine วิทาลิกเป็นผู้ตั้งต้นคิดค้นอีเธอเรียม โดยเขาได้เขียนและตีพิมพ์หลักการและแนวคิดของอีเธอเรียมใน white paper ซึ่งตีพิมพ์ในปี 2013 ก่อนที่จะมาร่วมพัฒนาอีเธอเรียมร่วมกับผู้ร่วมก่อตั้งและทีมงานจนเกิดเป็น Ethereum Foundation ปัจจุบัน วิทาลิกยังคงทำงานเป็นนักวิจัยภายใน Ethereum Foundation

อ่านบทความอื่นๆ ของวิทาลิกเพิ่มเติมได้ที่นี่ ความรู้จักอีเธอเรียมเพิ่มเติมได้ที่ Ethereum.org

อ่าน #ReadingCrypto EP.02 - Why Decentralization Matters โดย Chris Dixon (แปลไทย) ได้ที่นี่👇

https://mirror.xyz/nuchanucha.eth/aFTHCxpnlU-CAeDJlhwtXt0M1jymyNTadAlAqYULGs0

[Disclaimer: I do not own the copyright of this article. The copyright rightfully remains with the writer. I translated this article with an intention of distributing knowledge to the wider crypto community in Thailand; as a part of my own crusade for democratising Web3 and open internet knowledge, which I just embarked recently. If you have any concerns or questions, please kindly DM me via Twitter.]

[Disclaimer: เราไม่ได้เป็นเจ้าของลิขสิทธิ์เนื้อหานี้ ลิขสิทธิ์เนื้อหายังคงอยู่กับตัวผู้เขียนเราแปลบทความนี้ด้วยความตั้งใจที่จะช่วยเผยแพร่ความรู้ให้แก่ชุมชนคริปโตในไทย ในฐานะสิ่งที่เราอยากทำคือการกระจายความรู้เกี่ยวกับคริปโต, Web3 และ Open Internet ไปสู่วงกว้างมากขึ้น ถ้ามีคำถามหรือข้อกังวล ติดต่อเราผ่าน DM ได้บน Twitter ค่ะ]

#ReadingCrypto EP.01 The Meaning of Decentralization | ความหมายของการกระจายศูนย์

ผู้เขียน: วิทาลิก บิวเทอริน (Vitalik Buterin) บทความต้นฉบับตีพิมพ์เมื่อวันที่ 6 กุมภาพันธ์ 2017 อ่านความเรียงต้นฉบับภาษาอังกฤษได้ที่นี่ อ่าน Translator’s Note ได้ที่นี่

[ความเรียงภาคภาษาไทยนี้เป็นส่วนหนึ่งของซีรีส์ #ReadingCrypto ซีรีส์แปลความเรียงเท็กซ์หลัก (canonical text) ภาษาอังกฤษที่เกี่ยวกับปรัญชา, แนวคิด, วัฒนธรรม และประวัติศาสตร์ของคริปโต, Web 3.0 และอินเตอร์เน็ต]

“การกระจายศูนย์” (Decentralization) เป็นคำที่ถูกใช้บ่อยที่สุดคำหนึ่งในพื้นที่ของเศรษฐศาสตร์คริปโต (cryptoeconomics) และมักจะถูกมองว่าเป็นเหตุผลของการมีอยู่ของบล็อกเชนอย่างแท้จริง แต่กระนั้น มันก็เป็นคำที่ถูกนิยามไว้ได้แย่มากที่สุดคำหนึ่งเช่นกัน งานวิจัยกว่าหลายพันชั่วโมง และพลังการประมวลผลแฮช (hashpower) มูลค่ากว่าหลายพันล้านเหรียญฯ ถูกลงไปกับจุดประสงค์หนึ่งเดียวของการทำให้เกิดการกระจายศูนย์ อีกทั้งยังต้องบำรุงรักษา และพัฒนาให้ดียิ่งขึ้นไป และเมื่อใดที่การถกเถียงเริ่มดุเดือด มันเป็นเรื่องแสนจะปกติที่ฝ่ายเสนอของโพรโทคอลนั้นๆ (หรือส่วนขยายของโพรโทคอล) จะอ้างว่าข้อเสนอของเหล่าฝ่ายค้านทั้งหลายต่าง “รวมศูนย์” (centralized) ซึ่งถือว่าเป็นข้อโต้แย้งไม้ตายที่ล้มคู่แข่งได้อย่างชะงัด

อย่างไรก็ดี มักจะเกิดความสับสนบ่อยๆ ว่าแท้จริงแล้ว คำนี้หมายความว่าอย่างไรกันแน่ ขอยกกรณีตัวอย่าง ลองพิจารณาแผนภาพแสนไร้ประโยชน์แต่พบเห็นได้ทั่วไป อย่างแผนภาพด้านล่างนี้:

รูป.1 (ก) รวมศูนย์ (ข) กระจายศูนย์ (ค) เครือข่ายแบบกระจาย

คราวนี้ ลองมาดูสองคำตอบในกระทู้ “อะไรคือความแตกต่างระหว่างการกระจายและการกระจายศูนย์” บน Quora กัน คำตอบแรกหยิบยกแผนภาพด้านบนราวกับเป็นนกแก้วนกขุนทอง ส่วนคำตอบที่สองก็แสดงความเห็นที่แตกต่างไปอย่างสิ้นเชิงว่า “การกระจายหมายถึงว่า ไม่ใช่ทุกธุรกรรมจะถูกประมลผลในแห่งเดียวกัน” แต่ “การกระจายศูนย์หมายถึงว่า ไม่มีผู้ใดผู้หนึ่งที่จะมีอำนาจสามารถควบคุมการประมวลผลได้” ในขณะเดียวกัน คำตอบอันดับหนึ่งในกลุ่มอีเธอเรียมบน Stack ก็ตอบด้วยแผนภาพที่มีลักษณะคล้ายคลึงกับแผนภาพด้านบนมาก แต่ด้วยตำแหน่งของคำว่า “การกระจายศูนย์” และ “การกระจาย” นั้นสลับที่กัน! ชัดเจนแล้วว่า คำชี้แจงมันอยู่ในลำดับ!

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

• การกระจาย(หรือรวม)ศูนย์เชิงสถาปัตยกรรม - ระบบประกอบขึ้นจากคอมพิวเตอร์ที่จับต้องได้จำนวนกี่เครื่อง? ระบบยังสามารถดำเนินการต่อได้แม้คอมพิวเตอร์เหล่านั้นเกิดเสียหายในคราวเดียวสูงสุดกี่เครื่อง?

• การกระจาย(หรือรวม)ศูนย์เชิงการเมือง - มีคนกี่คนหรือองค์กรกี่กลุ่มที่มีอำนาจในการควบคุมคอมพิวเตอร์ที่ระบบกำลังวิ่งอยู่ทั้งหมดได้อย่างเบ็ดเสร็จ?

• การกระจาย(หรือรวม)ศูนย์เชิงตรรกะ - อินเตอร์เฟสและโครงสร้างข้อมูลที่ระบบนำเสนอและดำเนินการอยู่ ดูแล้วเหมือนเป็นวัตถุที่เป็นมวลก้อนใหญ่ชิ้นเดียว หรือฝูงอสัณฐานไร้รูปร่างตายตัวมากกว่ากัน? วิธีการค้นหาคำตอบด้วยตัวเองแบบง่ายๆ ก็คือ ถ้าคุณผ่าระบบออกเป็นสองส่วน โดยรวมทั้งฝั่งผู้ให้บริการและผู้ใช้งานแล้ว ทั้งสองส่วนจะสามารถทำงานได้ตามปกติในฐานะหน่วยย่อยอิสระได้หรือไม่?

เราสามารถลองนำมิติทั้งสามมาใส่ลงในแผนภาพนี้ได้:

พึงสังเกตว่า หลายข้อในชาร์ตนี้ถูกวางอย่างหยาบๆ และสร้างข้อโต้แย้งได้อีกมาก แต่มาลองดูตามไปทีละอัน:

• บริษัทแบบดั้งเดิมมีการเมืองแบบรวมศูนย์ (ซีอีโอหนึ่งคน) ใช้สถาปัตยกรรมแบบรวมศูนย์ (สำนักงานใหญ่หนึ่งแห่ง) และดำเนินการด้วยตรรกะแบบรวมศูนย์ (ไม่สามารถแบ่งครึ่งบริษัทได้)

• ระบบประมวลกฎหมายพึ่งพิงคณะร่างกฎหมายแบบรวมศูนย์ ในขณะที่ระบบกฎหมายจารีตประเพณีสร้างขึ้นจากการตัดสินใจที่ผ่านมาของผู้พิพากษาแต่ละคน ระบบประมวลกฎหมายยังพอจะใช้สถาปัตยกรรมแบบกระจายศูนย์ เนื่องจากมีศาลหลายแห่ง ที่ถึงแม้จะให้น้ำหนักกับดุลยพินิจของเจ้าหน้าที่ แต่ระบบกฎหมายจารีตประเพณีก็ยังให้น้ำหนักมากกว่า อย่างไรก็ดี ทั้งสองต่างมีตรรกะที่รวมศูนย์ (“กฎหมายก็คือกฎ”)

• ภาษามีตรรกะแบบกระจายศูนย์ ภาษาอังกฤษที่อลิซใช้สื่อสารกับบ็อบ ไม่จำเป็นต้องสอดคล้องกับภาษาอังกฤษที่ชาร์ลีใช้สื่อสารกับเดวิดเลย ภาษาไม่ต้องมีโครงสร้างแบบรวมศูนย์เพื่อที่จะให้มันคงอยู่ได้ และกฎไวยากรณ์ภาษาอังกฤษไม่ได้ถูกสร้างหรือถูกกำหนดโดยใครคนใดคนหนึ่ง (แม้ว่าภาษาเอสเปรันโตเดิมทีจะถูกคิดค้นโดยลุดวิก ซาเมนฮอฟ (Ludwig Zamenhof) แต่ปัจจุบันมันก็ทำงานเหมือนกับภาษาที่ใช้กันอยู่ในสมัยนี้มากกว่า ซึ่งค่อยๆ วิวัฒน์โดยปราศจากผู้คุมกฎ)

• บิตทอร์เรนต์ทำงานแบบกระจายศูนย์ในเชิงตรรกะเช่นเดียวกับภาษาอังกฤษ เครือข่ายการส่งเนื้อหา (content delivery network) ก็คล้ายกัน แต่ว่ามันถูกควบคุมโดยบริษัทใดบริษัทหนึ่ง

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

บ่อยครั้งที่เวลาใครพูดถึงคุณงามความดีของบล็อกเชน พวกเขามักจะเอ่ยถึงประโยชน์ด้านความสะดวกของการมี “ฐานข้อมูลกลางเพียงแห่งเดียว” การรวมศูนย์เช่นนี้ถือเป็นการรวมศูนย์เชิงตรรกะ และการรวมศูนย์ประเภทนี้อาจจะกล่าวได้ในหลายๆ กรณีว่าเป็นเรื่องที่ดี (แต่ฮวน เบเนต์ (Juan Benet) จาก IPFS จะผลักดันให้เกิดการกระจายศูนย์เชิงตรรกะในทุกๆ ที่ที่เป็นไปได้ เพราะระบบที่ใช้ตรรกะแบบกระจายศูนย์มักจะเอาชีวิตรอดจากการแบ่งส่วนเครือข่ายได้อย่างเก่งกาจ และทำงานได้ดีในพื้นที่ที่มีการเชื่อมต่อที่ไม่ค่อยดี เป็นต้น ลองอ่านต่อได้ในบทความนี้บน Scuttlebot ที่พูดถึงการสนับสนุนตรรกะแบบกระจายศูนย์อย่างตรงไปตรงมา)

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

การรวมศูนย์เชิงตรรกะจะทำให้การกระจายศูนย์เชิงสถาปัตยกรรมเกิดได้ยากขึ้น แต่ก็ไม่ใช่ว่าจะเป็นเรื่องที่ไปไม่ได้ ดูอย่างเครือข่ายฉันทามติ (consensus) แบบกระจายศูนย์ที่แสดงให้เห็นแล้วว่ามันใช้การได้จริง แต่อาจจะยากกว่าการบำรุงรักษาบิตทอร์เรนต์ นอกจากนั้น การรวมศูนย์เชิงตรรกะจะทำให้การกระจายศูนย์เชิงการเมืองเกิดขึ้นได้ยากขึ้น มันยากที่จะคลี่คลายปัญหาของข้อขัดแย้งอันรุนแรงภายในระบบที่ใช้ตรรกะเชิงรวมศูนย์ ด้วยเพียงแค่ “การที่ทุกคนตกลงยอมให้แต่ละคนทำตามที่ตัวเองต้องการและเดินหน้ากันต่อไป”

คำถามต่อไปคือ ทำไมการกระจายศูนย์ถึงมีประโยชน์ตั้งแต่แรก? มีข้อโต้แย้งหลายๆ ข้อที่มักจะถูกยกขึ้นมา:

• ความทนทานต่อความผิดพลาด - ระบบแบบกระจายศูนย์มีแนวโน้มที่จะล้มเหลวโดยบังเอิญน้อยกว่า เพราะพวกมันพึ่งพาส่วนประกอบที่แยกส่วนกันซึ่งมีความไปได้ต่ำว่าจะล้มเหลว

• ความต้านทานต่อการถูกโจมตี - การโจมตี ทำลาย หรือแทรกแซงระบบกระจายศูนย์มีค่าใช้จ่ายที่แพงกว่ามาก เนื่องจากระบบเช่นนี้ไม่มีจุดเปราะบางที่สามารถโจมตีได้ด้วยค่าใช้จ่ายต่ำกว่าขนาดเศรษฐกิจโดยรวมของระบบทั้งหมดอย่างมีนัยยะ

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

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

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

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

บล็อกเชนในรูปแบบปัจจุบัน [ปี 2017] สามารถป้องกันความล้มเหลวพร้อมกันได้หรือไม่? ก็อาจจะไม่ได้ทุกครั้ง ลองพิจารณาสถานการณ์ต่อไปนี้:

• โหนด (node) ทุกตัวในบล็อกเชนทำงานอยู่บนซอฟต์แวร์ไคลเอ็นต์ (software client) เดียวกัน และปรากฏว่าซอฟต์แวร์ไคลเอ็นต์ตัวนี้เกิดมีบั๊ก

• โหนดทุกตัวในบล็อกเชนทำงานอยู่บนซอฟต์แวร์ไคลเอ็นต์เดียวกัน และทีมนักพัฒนาซอฟต์แวร์นี้ ปรากฏว่าเป็นพวกสามานย์

• ทีมนักวิจัยที่ทำข้อเสนอการอัพเกรดของโพรโทคอล กลายเป็นพวกคนสามานย์

• ในบล็อกเชนแบบ Proof of Work (PoW) กว่า 70 เปอร์เซ็นต์ของนักขุดอยู่ในประเทศเดียวกัน และรัฐบาลของประเทศนั้นเกิดตัดสินใจที่จะยึดเหมืองขุดทั้งหมดด้วยเหตุผลทางความมั่นคงของชาติ

• ฮาร์ดแวร์สำหรับการขุดส่วนใหญ่ถูกสร้างโดยบริษัทเดียวกัน และบริษัทนี้ถูกติดสินบนหรือถูกจูงจมูกให้สร้างประตูหลังบ้านที่สามารถปิดฮาร์ดแวร์ได้ตามอำเภอใจ

• ในบล็อกเชนแบบ Proof of Stake (PoS) เหรียญกว่า 70 เปอร์เซ็นต์ถูก stake ไว้กับกระดานเทรดเพียงเจ้าเดียว

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

• มันสำคัญมากที่จะต้องมีการลงมือหลากหลายรูปแบบที่เพื่อให้เกิดการแข่งขัน

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

• ทีมนักพัฒนาหลักและทีมนักวิจัยควรจะเป็นทีมที่มาจาก

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

คราวนี้ เราลองมาดูในฝั่งของความต้านทานต่อการถูกโจมตีบ้าง ในโมเดลจำลองทางเศรษฐศาสตร์แบบเพียวๆ บางอัน คุณอาจจะเจอผลลัพธ์ว่าในบางครั้งการกระจายศูนย์ก็ไม่ได้มีผลอะไรเลย ถ้าคุณสร้างโพรโทคอลที่รับประกันว่าวาลิเดเตอร์ (validator) จะต้องสูญเสียเงินจำนวน 50 ล้านเหรียญฯ หากเกิดการโจมตี 51เปอร์เซ็นต์ (51% attack) (เช่น การยกเลิกยอดบัญชีที่ถูกบันทึกไปแล้ว (finality reversion)) ด้วยเหตุนี้ มันไม่ได้สลักสำคัญอะไรเลย ถ้าวาลิเดเตอร์ทั้งหลายจะถูกควบคุมโดยบริษัทแห่งเดียวหรือหนึ่งร้อยบริษัท เนื่องจากมาร์จิ้นความมั่นคงทางเศรษฐกิจจำนวน 50 ล้านเหรียญฯ ก็ยังเท่ากับมาร์จิ้นความมั่นคงทางเศรษฐกิจจำนวน 50 ล้านเหรียญฯ ความจริงแล้วเหตุผลทางทฤษฎีเกมเชิงลึก ว่าทำไมการรวมศูนย์นั้นอาจจะช่วยทำให้ความตระหนักรู้เกี่ยวกับความมั่นคงทางเศรษฐกิจให้เพิ่มสูงสุด (โมเดลการคัดเลือกธุรกรรมในบล็อกเชนที่มีอยู่ ณ ปัจจุบัน [ปี 2017] ได้สะท้อนถึงข้อมูลเชิงลึกนี้ เพราะการรวมธุรกรรมเข้าไปในบล็อกผ่านนักขุด/ผู้เสนอบล็อก แท้จริงแล้วเป็นเผด็จการที่มีการหมุนเวียนอย่างรวดเร็ว)

อย่างไรก็ตาม เมื่อคุณได้เปิดรับโมเดลเศรษฐกิจที่อุดมสมบูรณ์กว่า และโดยเฉพาะโมเดลที่ยอมรับว่ามีความเป็นไปได้ที่จะเกิดการบีบบังคับขู่เข็ญ (หรือสิ่งที่ร้ายแรงน้อยกว่านั้น เช่น การโจมตี DoS ที่พุ่งเป้าไปยังโหนด) การกระจายศูนย์จะมีความสำคัญมากยิ่งขึ้น ถ้าคุณเกิดขู่กรรโชกใครคนหนึ่งด้วยความตาย เงินจำนวน 50 ล้านเหรียญฯ จะหมดความหมายสำหรับพวกเขาในทันที แต่ถ้าเงินจำนวน 50 ล้านเหรียญฯ ถูกกระจายไปให้คนสิบคน คุณจะต้องขู่กรรโชกคนเพิ่มขึ้นเป็นสิบเท่าตัว และยังต้องลงมือข่มขู่ทุกคนพร้อมๆ กันอีกด้วย โดยทั่วไปแล้ว โลกสมัยใหม่ในหลายๆ ครั้งถูกนิยามลักษณะผ่านความไม่สมมาตรของการโจมตี/การป้องกัน ซึ่งมักจะเอื้อประโยชน์ต่อผู้โจมตี ยกตัวอย่างเช่น ตึกที่มีค่าใช้จ่ายในการก่อสร้างเป็นจำนวนเงิน 10 ล้านเหรียญฯ อาจจะใช้เงินน้อยกว่า 100,000 เหรียญฯ ในการทำลาย แต่ทั้งนี้การยกระดับ (leverage) ของผู้โจมตีมักจะเป็นแบบ sublinear เช่น ถ้าตึกแห่งหนึ่งใช้เงินจำนวน 10 ล้านเหรียญฯ ในการก่อสร้าง และใช้เงิน 100,000 เหรียญฯ ในการทำลาย ตึกที่ใช้เงินหนึ่งล้านเหรียญฯ ในการสร้าง ตามความจริงแล้วก็น่าจะใช้เงินประมาณ 30,000 เหรียญฯ ในการทำลาย ยิ่งจำนวนน้อยยิ่งให้อัตราส่วนที่ดี

แล้วการพินิจพิเคราะห์เช่นนี้จะนำไปสู่อะไร? ลำดับแรก มันให้ประโยชน์ฝั่ง Proof of Stake เหนือฝั่ง Proof of Work อย่างยิ่งยวด เพราะฮาร์ดแวร์คอมพิวเตอร์นั้นง่ายต่อการแกะรอย, ควบคุม, และโจมตี ส่วนเหรียญนั้น สามารถถูกเก็บซ่อนได้ง่ายกว่ามาก (นอกจากนี้ Proof of Stake ยังสามารถต่อต้านการโดนโจมตีได้อย่างแข็งแกร่งเพราะเหตุผลประการอื่นๆ ด้วย) ลำดับที่สอง มันเป็นเหตุผลของการสนับสนุนให้เกิดการกระจายตัวของทีมนักพัฒนาไปในวงกว้าง ซึ่งรวมไปถึงการกระจายตัวทางภูมิศาสตร์ ลำดับที่สาม มันเป็นการกล่าวอย่างกลายๆ ว่าทั้งโมเดลทางเศรษฐศาสตร์และโมเดลการต่อต้านความล้มเหลวจำเป็นต้องถูกนำมาพิจารณาระหว่างการออกแบบโพรโทคอลฉันทามติด้วย

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

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

ในกรณีโพรโทคอลบล็อกเชน การพินิจพิเคราะห์ทางคณิตศาสตร์และเศรษฐศาสตร์ที่อยู่เบื้องหลังเกราะกำบังของฉันทามติ มักจะพึ่งพาโมเดลตัวเลือกแบบไม่ร่วมมือกัน หรือการอนุมานว่าเกมประกอบไปด้วยผู้เล่นตัวเล็กหลายๆ คนที่ตัดสินใจด้วยตนเอง ถ้าเมื่อใดที่มีผู้เล่นคนไหนเกิดมีพลังการขุดมากกว่า ⅓ ในระบบ Proof of Work พวกเขาจะสามารถได้รับกำไรก้อนใหญ่มหาศาลผ่านการขุดแบบเห็นแก่ตัว แต่กระนั้น เราสามารถพูดได้อย่างเต็มปากเต็มคำหรือว่าโมเดลตัวเลือกแบบไม่ร่วมมือกันนั้นสามารถปฏิบัติได้จริง เมื่อเครือข่ายการขุดของบิตคอยน์กว่า 90 เปอร์เซ็นร่วมมือกันได้ดีในระดับที่สามารถโผล่มาที่งานสัมมนาเดียวกันได้อย่างพร้อมหน้าพร้อมตา?

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

แต่กระนั้นก็ดี ประเด็นนี้ได้แสดงให้เห็นความย้อนแยงในระดับพื้นฐาน ชุมชนหลายๆ แห่งรวมไปถึงอีเธอเรียม มักจะถูกชื่นชมว่ามีสปิริตที่แข็งแกร่ง และสามารถร่วมแรงร่วมใจกันพัฒนา, ปล่อย และเปิดใช้งาน hard fork ได้อย่างรวดเร็ว เพื่อแก้ปัญหาการปฏิเสธการให้บริการ (denial-of-service) ในโพรโทคอลภายในหกวัน แต่จะทำอย่างไรให้เราสามารถส่งเสริมและพัฒนาการร่วมมือในรูปแบบที่ดีงามเช่นนี้ แต่ในขณะเดียวกันป้องกัน “การร่วมมือที่เลวร้าย” ที่เกิดจากนักขุดพยายามจะเอาเปรียบคนอื่นๆ ผ่านการร่วมมือเพื่อโจมตีแบบ 51 เปอร์เซ็นต์?

ในการตอบคำถามนี้ มีสามทางด้วยกัน:

• ไม่ต้องสนใจที่จะหยุดยั้งการร่วมมือกันแบบที่ไม่เป็นที่ต้องการ แต่พยายามสร้างโพรโทคอลที่สามารถต่อต้านมันได้ดีกว่า

• พยายามหาสื่อที่ดีที่ทำให้เกิดการร่วมมือในระดับที่จะทำให้โพรโทคอลพัฒนาไปข้างหน้าไป แต่ไม่เพียงพอที่จะทำให้เกิดการโจมตีได้

• พยายามหาข้อแตกต่างระหว่างการร่วมมือที่มีประโยชน์และการร่วมมือที่เป็นอันตราย และทำข้อแรกให้ง่ายลง ทำข้อหลังให้ยากขึ้น

วิธีแรกเป็นส่วนประกอบขนาดใหญ่ของปรัญชาการออกแบบแคสเปอร์ (Casper) แต่กระนั้น โดยลำพังแค่ตัวมันเองนั้นไม่เพียงพอ เพราะการพึ่งพาเศรษฐศาสตร์เพียงอย่างเดียวไม่สามารถจัดการกับข้อกังวลอีกสองข้อเกี่ยวกับการกระจายศูนย์ได้ ส่วนข้อที่สองนั้นยากที่จะออกแบบและสร้างให้เป็นรูปธรรม โดยเฉพาะในระยะยาว แต่มันมักจะเกิดขึ้นด้วยความบังเอิญ ยกตัวอย่างเช่น ข้อเท็จจริงที่ว่านักพัฒนาหลักของบิตคอยน์มักจะพูดภาษาอังกฤษแต่เหล่านักขุดส่วนใหญ่พูดภาษาจีนถือได้ว่าเป็นความบังเอิญที่น่ายินดี เพราะมันได้ทำให้เกิดการปกครองโดยใช้ “ระบบสองสภา” (bicameral) ที่ทำให้การร่วมมือกันยากขึ้นไปอีก ซึ่งมีข้อดีข้างเคียงด้วยการลดความเสี่ยงของการเกิดความล้มเหลวพร้อมกัน เนื่องจากทั้งชุมชนที่ใช้ภาษาอังกฤษและชุมชนที่ใช้ภาษาจีนน่าจะมีการพูดคุยกันด้วยเหตุผล ซึ่งน่าจะเป็นบทสนทนาที่แยกวงกัน เนื่องจากระยะทางที่ห่างกันและความยากในการสื่อสาร เพราะฉะนั้นความเป็นไปที่คนทั้งสองกลุ่มจะทำผิดพลาดในเรื่องเดียวกันได้น้อยลง

ข้อที่สามนั้นเป็นความท้าทายในฝั่งสังคมเหนือสิ่งอื่นใด ทางออกในส่วนนี้อาจจะรวมไปถึง:

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

• สนับสนุนการสื่อสารระหว่าง “ฝั่งต่างๆ ภายในตลาด” ด้วยบริบทเดียวกัน เพื่อลดความเป็นไปได้ที่กลุ่มวาลิเดเตอร์, กลุ่มนักพัฒนา, หรือกลุ่มนักขุด จะเริ่มเห็นตัวเองเป็น “ชนชั้น” ซึ่งควรทำงานร่วมกันเพื่อปกป้องผลประโยชน์ของตัวเองจากชนชั้นอื่นๆ

• ออกแบบโพรโทคอลในรูปแบบที่จะลดแรงจูงใจสำหรับวาลิเดเตอร์/นักขุด ให้เข้าไปข้องแวะกับ “ความสัมพันธ์สุดพิเศษ” แบบหนึ่งต่อหนึ่ง หรือระบบเครือข่ายการถ่ายโอนข้อมูลแบบรวมศูนย์ และกลไกที่มีความคล้ายคลึงกับซุปเปอร์โพรโทรคอลยักษ์ใหญ่

• บรรทัดฐานที่ชัดเจนว่าคุณสมบัติพื้นฐานที่โพรโทคอลควรจะมีมีอะไรบ้าง และสิ่งที่ไม่ควรจะทำ หรืออย่างน้อยทำได้แค่ภายในสถานการณ์สุดโต่งไม่คาดฝัน

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

เกี่ยวกับผู้เขียน วิทาลิก บิวเทอริน (Vitalik Buterin) คือนักวิจัย โปรแกรมเมอร์ นักคิด นักเขียน และผู้ร่วมก่อตั้ง Bitcoin Magazine วิทาลิกเป็นผู้ตั้งต้นคิดค้นอีเธอเรียม โดยเขาได้เขียนและตีพิมพ์หลักการและแนวคิดของอีเธอเรียมใน white paper ซึ่งตีพิมพ์ในปี 2013 ก่อนที่จะมาร่วมพัฒนาอีเธอเรียมร่วมกับผู้ร่วมก่อตั้งและทีมงานจนเกิดเป็น Ethereum Foundation ปัจจุบัน วิทาลิกยังคงทำงานเป็นนักวิจัยภายใน Ethereum Foundation

อ่านบทความอื่นๆ ของวิทาลิกเพิ่มเติมได้ที่นี่ ความรู้จักอีเธอเรียมเพิ่มเติมได้ที่ Ethereum.org

อ่าน #ReadingCrypto EP.02 - Why Decentralization Matters โดย Chris Dixon (แปลไทย) ได้ที่นี่👇

https://mirror.xyz/nuchanucha.eth/aFTHCxpnlU-CAeDJlhwtXt0M1jymyNTadAlAqYULGs0

[Disclaimer: I do not own the copyright of this article. The copyright rightfully remains with the writer. I translated this article with an intention of distributing knowledge to the wider crypto community in Thailand; as a part of my own crusade for democratising Web3 and open internet knowledge, which I just embarked recently. If you have any concerns or questions, please kindly DM me via Twitter.]

[Disclaimer: เราไม่ได้เป็นเจ้าของลิขสิทธิ์เนื้อหานี้ ลิขสิทธิ์เนื้อหายังคงอยู่กับตัวผู้เขียนเราแปลบทความนี้ด้วยความตั้งใจที่จะช่วยเผยแพร่ความรู้ให้แก่ชุมชนคริปโตในไทย ในฐานะสิ่งที่เราอยากทำคือการกระจายความรู้เกี่ยวกับคริปโต, Web3 และ Open Internet ไปสู่วงกว้างมากขึ้น ถ้ามีคำถามหรือข้อกังวล ติดต่อเราผ่าน DM ได้บน Twitter ค่ะ]