สถานะที่น่าเศร้าของการตรวจสอบ Web3 และสิ่งที่สามารถทำได้

Balancer โปรโตคอลเก่าแก่และได้รับการตรวจสอบอย่างดี เพิ่งถูก "แฮ็ก" เมื่อไม่นานมานี้ Yearn Finance ที่ได้รับการตรวจสอบอย่างดีเช่นกันก็เป็นเช่นเดียวกัน หลายปีก่อน Euler Finance ถูก "แฮ็ก" ผ่านฟังก์ชันที่เพิ่มเข้ามาเพื่อตอบสนองต่อการตรวจสอบครั้งก่อน USPD ได้รับการตรวจสอบก่อนการปรับใช้ แต่กระบวนการปรับใช้ที่ไม่ได้รับการตรวจสอบนั้นเองถูกแฮ็ก นำไปสู่การตัดจำหน่ายทั้งหมดภายในประมาณ 3 เดือนหลังเปิดตัว ไม่มีใครที่ติดตามเรื่องนี้เชื่อว่าการตรวจสอบคือการรับประกันว่าบางอย่างปลอดภัย หลายคนตั้งคำถามว่าการตรวจสอบมีค่าอะไรเลย

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

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

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

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

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

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

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

Jovay

Jovay เป็น L2 ที่เกี่ยวข้องกับ Ant Financial หรือ Alibaba หรืออะไรในพื้นที่ทั่วไปนั้น แต่มันไม่สำคัญจริงๆ ว่า Jovay ทำอะไร มันเป็นสิ่งที่สร้างจากซอฟต์แวร์จากองค์กรขนาดใหญ่และได้รับเงินทุนดี การตรวจสอบนี้ระบุปัญหาแปดข้อ:

1. ข้อผิดพลาดในการเขียนโปรแกรมที่ถูกต้องซึ่งได้รับการแก้ไขในภายหลัง
2. โปรโตคอลไม่ได้เป็นแบบไร้ความไว้วางใจ นี่เป็นปัญหาในลักษณะหนึ่ง แต่มันก็เป็นส่วนหลักของการออกแบบด้วย
3. การโจมตี "fake-recharge" ที่ใช้กับส่วนกว้างของระบบนิเวศและไม่เฉพาะเจาะจงกับโครงการ
4. เซิร์ฟเวอร์ RPC ใช้ HTTP แทน HTTPS อินเทอร์เฟซเหล่านี้ไม่ประมวลผลข้อมูลลับ สิ่งนี้ใช้กับเว็บไซต์อ่านอย่างเดียวที่ปลอดภัยอย่างสมบูรณ์หลายพันล้าน
5. คอมพิวเตอร์ควอนตัมก่อให้เกิดความเสี่ยงต่อ Ethereum โอเค อันนี้ตรงประเด็นมาก
6. สัญญาอัจฉริยะ EVM อาจมีช่องโหว่ ไม่ล้อเล่น มันบอกว่า "สัญญาอัจฉริยะ Evm มีความอ่อนแอต่อเวกเตอร์การโจมตีต่างๆ เนื่องจากการปรับใช้โค้ดที่ไม่สามารถเปลี่ยนแปลงและการโต้ตอบที่ซับซ้อน อาจนำไปสู่การขโมยเงิน,.." โอเค อีกครั้งเคารพโฟกัสแคบๆ ของการตรวจสอบนี้จริงๆ
7. การออกแบบ sequencer ขึ้นอยู่กับ MEV เหมือนกับส่วนอื่นๆ ทั้งหมดของระบบนิเวศ Ethereum มันยังมืดเกินไปในตอนกลางคืนด้วย
8. คุณภาพของโค้ดสามารถปรับปรุงได้ ไม่เหมือนกับโค้ดอื่นๆ ส่วนใหญ่ที่เขียนตั้งแต่รุ่งอรุณของการประมวลผล

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

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

Hyperliquid

Hyperliquid ได้เผยแพร่รายงานการตรวจสอบหลายฉบับ รายงานการตรวจสอบฉบับแรกพบปัญหาหกข้อและรายงานฉบับที่สองยืนยันว่าได้รับการแก้ไขแล้ว แต่ขอบเขตของการตรวจสอบไม่รวม:

1. สัญญาอัจฉริยะอื่นๆ ส่วนหนึ่งของระบบ Hyperliquid
2. ส่วนประกอบนอกเชน เช่น validators
3. ส่วนประกอบส่วนหน้า
4. โครงสร้างพื้นฐานที่เกี่ยวข้องกับโครงการ
5. การดูแลคีย์

สิ่งเหล่านั้นดูเหมือนพื้นที่ปัญหาที่เป็นไปได้! ทั้งหมดที่ได้รับการตรวจสอบคือสัญญาบริดจ์เดียว แต่ระบบนั้น คือ มันซับซ้อนกว่านั้นมาก

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

Ondo

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

การตรวจสอบนี้ระบุว่าระบบอาจพังทลายหากสเตเบิลคอยน์ที่เกี่ยวข้อง depeg มากเกินไป พวกเขาบรรยายว่าระบบ "จะอนุญาตให้มีการสร้างโทเค็น OUSG มากเกินไปในช่วงเหตุการณ์ USDC depeg" ในท้ายที่สุด "วิธีแก้ปัญหา" ที่พวกเขานำมาคืออ้างอิง Chainlink oracle และสวิตช์ปิดในกรณีที่ราคาถูกรายงานว่าต่ำเกินไป ดังนั้นแทนที่จะระเบิดด้วยมูลค่าที่ร่วง โปรโตคอลจะหยุดด้วยมูลค่าที่ร่วง ใช่ นี่ไม่ใช่ปัญหาที่แก้ไขได้เนื่องจากไม่มีกลไกเพื่อหลีกเลี่ยงผลลัพธ์ที่สูญเสียมูลค่าหาก USDC ระเบิด และสอดคล้องกับข้อเท็จจริงนั้น วิธีแก้ปัญหาไม่ได้แก้ไขอะไรจริงๆ

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

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

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

คุณสามารถเห็นวิวัฒนาการนี้ในการตรวจสอบของโครงการนี้

Mutuum Finance

ตอนนี้เรามี reductio ad absurdum ของการตรวจสอบ อันนี้ระบุปัญหาเดียว:

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

จากนั้นมีรายละเอียด multisig จำนวนมาก และในที่สุดคำตอบของผู้ตรวจสอบ:

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

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

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

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

การปรับปรุง

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

แต่มีการปรับปรุงที่แท้จริงไม่กี่อย่างที่เราสามารถแนะนำได้ Ethena นำทางโดยการอธิบายบางส่วนของโหมดความล้มเหลวมากมายของผลิตภัณฑ์ของพวกเขาล่วงหน้า ทีมสอดคล้องกับข้อความว่า USDe ไม่ได้ปราศจากความเสี่ยง และพวกเขาสรุปวิธีที่อาจมีปัญหา ผลิตภัณฑ์รอดชีวิต ด้วยอุปสรรคเล็กน้อย และค่อนข้างใหญ่ในปัจจุบัน สิ่งนี้ให้จุดปฏิบัติการแก่นักลงทุน: ยืนยันว่าโครงการซื่อสัตย์เกี่ยวกับ "การโจมตีที่เกี่ยวข้องกับการเงิน" ที่อาจมีอยู่

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

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

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

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

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

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

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