บริษัทพัฒนา Web3: คำแนะนำในการเลือกพันธมิตรที่เหมาะสม

บริษัทพัฒนา Web3 ไม่ใช่เพียงทีมที่เขียน Solidity หรือเชื่อมต่อวอลเล็ทกับส่วน frontend เท่านั้น ผู้ให้บริการที่แข็งแกร่งที่สุดจะรวมการวิศวกรรมโปรโตคอล ความปลอดภัยของสมาร์ทคอนแทรกต์ การออกแบบโครงสร้างพื้นฐาน การจัดดัชนีข้อมูล ความรู้ด้านการปฏิบัติตามกฎหมาย และการส่งมอบผลิตภัณฑ์ไว้ในกระบวนการที่รับผิดชอบเดียวกัน ความแตกต่างนี้มีความสำคัญเพราะความล้มเหลวในชั้นการบูรณาการ—not เพียงแค่ในโค้ดคอนแทรกต์—ทำให้เกิดความสูญเสียหลายร้อยล้านดอลลาร์มาแล้ว

การโจมตีสะพาน Ronin ในเดือนมีนาคม 2022 ส่งผลให้มีมูลค่าประมาณ 625 ล้านดอลลาร์ ถูกขโมยหลังจากที่ผู้โจมตีแฮกข้อมูลรับรอง validator การโจมตีสะพาน Wormhole ในเดือนกุมภาพันธ์ 2022 ก่อให้เกิดความสูญเสียราว 320 ล้านดอลลาร์ ผ่านความล้มเหลวในการตรวจสอบ เหตุการณ์เหล่านี้แสดงให้เห็นว่าบริการพัฒนา Web3 ต้องครอบคลุมการบริหารจัดการคีย์ การยืนยันข้อความ การมอนิเตอร์ การควบคุมการปรับใช้ และการบริหารดำเนินงานควบคู่ไปกับฟังก์ชันของแอปพลิเคชัน

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

บริษัทพัฒนา Web3 ให้บริการอะไรจริงๆ?

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

ในทางปฏิบัติ การทำงานอย่างจริงจังมักครอบคลุมหลายชั้นที่เชื่อมต่อกัน:

• สถาปัตยกรรมผลิตภัณฑ์และโปรโตคอล: นิยามเส้นทางผู้ใช้ สมมติฐานความไว้วางใจ กระแสเศรษฐกิจ การอนุญาต และข้อกำหนดการอัปเกรด
• วิศวกรรมสมาร์ทคอนแทรกต์: การดำเนินการตรรกะ token, staking, lending, governance, marketplace, bridge หรือ treasury
• การเชื่อมต่อ frontend และวอลเล็ท: รองรับขั้นตอนการเซ็นชื่อ การสลับเครือข่าย การจำลองธุรกรรม การจัดการข้อผิดพลาด และการนามธรรมบัญชีที่เหมาะสม
• Backend และการจัดดัชนีข้อมูล: การสร้างเส้นทางเหตุการณ์ API บริการวิเคราะห์ ระบบแจ้งเตือน และกระบวนการทำ reconciliation
• โครงสร้างพื้นฐาน: การจัดการ RPC providers โหนด archive relayers การดูแลคีย์ สภาพแวดล้อมการปรับใช้ การสังเกตและความสามารถในการกู้คืนในกรณีฉุกเฉิน
• ความปลอดภัย: การทำ threat modelling การรีวิวโค้ด การทดสอบ การทำ penetration testing และการเตรียมรับมือเหตุการณ์
• การประสานงานด้านกฎระเบียบและการดำเนินงาน: เชื่อมโยงดีไซน์ทางเทคนิคกับการจำแนกประเภท token การอนุญาต การคุ้มครองข้อมูล และความต้องการเข้าใช้ตลาด

คำว่า บริการพัฒนา Web3 ควรถือเป็นหมวดหมู่การส่งมอบที่กว้าง ไม่ใช่คำพ้องความหมายเดียวกับ “การเขียนโปรแกรมสมาร์ทคอนแทรกต์” แพลตฟอร์ม staking อาจมีคอนแทรกต์ เว็บแอปพลิเคชัน ราคา oracle เครื่องคำนวณรางวัล subgraph กระเป๋าเงิน multisignature ของ treasury และบทบาทเชิงปฏิบัติการที่มีสิทธิพิเศษ การบกพร่องในส่วนใดส่วนหนึ่งขององค์ประกอบเหล่านี้อาจส่งผลกระทบต่อผลิตภัณฑ์ได้

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

ผลลัพธ์การส่งมอบทั่วไป

พื้นที่ส่งมอบ	ผลลัพธ์ที่พบบ่อย	ความเสี่ยงหลักหากละเว้น
การค้นพบ	ความต้องการ โมเดลภัยคุกคาม บันทึกการตัดสินใจด้านสถาปัตยกรรม	สร้างโมเดลความไว้วางใจผิดพลาด
ชั้นโปรโตคอล	คอนแทรกต์ อินเทอร์เฟซ สคริปต์ปรับใช้ การทดสอบ	ลอจิกหรือสิทธิ์ผิดพลาด
ชั้นแอปพลิเคชัน	อินเทอร์เฟซเว็บ/มือถือ ขั้นตอนวอลเล็ท UX	ข้อผิดพลาดการเซ็นชื่อ และการสูญเสียผู้ใช้
ชั้นข้อมูล	การจัดดัชนี API วิเคราะห์ข้อมูล กระบวนการทำ reconciliation	ยอดคงเหลือผิดพลาด หรือรายงานล้าสมัย
โครงสร้างพื้นฐาน	CI/CD การเข้าถึงโหนด ความลับ การมอนิเตอร์	เหตุการณ์ที่ไม่ถูกตรวจพบ หรือไม่สามารถกู้คืนได้
การรับรองความปลอดภัย	การแก้ไขข้อบกพร่อง การทดสอบ penetration การทำ runbooks	ปล่อยโค้ดโดยปราศจากหลักฐานการควบคุม

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

ผู้ก่อตั้งควรเลือกระหว่างบริษัทที่ปรึกษา Web3 กับทีมภายในอย่างไร?

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

การตัดสินใจควรอ้างอิงความเสี่ยง ความพร้อมของผลิตภัณฑ์ และความสามารถในแต่ละเฟส

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

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

โมเดลเชิงปฏิบัติการที่ใช้ได้ดีคือการแบ่งความรับผิดชอบเป็นสามช่วง:

1. การออกแบบสถาปัตยกรรมและนิยามความเสี่ยง: ใช้ผู้เชี่ยวชาญภายนอกท้าทายสมมติฐานและบันทึกขอบเขตความปลอดภัย
2. การสร้างและการตรวจสอบ: รวมความเชี่ยวชาญโปรโตคอลของบริษัทที่ปรึกษากับการเป็นเจ้าของผลิตภัณฑ์ภายใน
3. การเปลี่ยนผ่านด้านการดำเนินงาน: ต้องการ runbooks การถ่ายโอนความรู้การปรับใช้ การมอนิเตอร์ และระยะเวลาการสนับสนุนหลังเปิดตัว

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

กระบวนการเลือกบริษัทที่ปรึกษาควรรวมคำถามทางเทคนิค ไม่ใช่แค่พิจารณาพอร์ตโฟลิโอเท่านั้น เช่น:

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

บริษัทพัฒนา dapp ที่ดีควรพูดถึงเรื่องสถานะความล้มเหลวของธุรกรรม การ reorganisations ของเครือข่าย การจัดการ nonce การประมาณค่า gas และความไม่เข้ากันของวอลเล็ท — ไม่ใช่แค่การออกแบบ UI เท่านั้น

สิ่งที่ควรรวมในพัฒนาการ Web3 แบบกำหนดเอง?

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

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

ส่วนประกอบหลักของการสร้างแบบกำหนดเอง

1. การออกแบบโปรโตคอลและเศรษฐศาสตร์

ทีมควรบันทึกการเปลี่ยนแปลงปริมาณ supply, กระแส fee, กฎเกณฑ์ collateral, เงื่อนไข liquidation, การปล่อยรางวัล, อำนาจหยุดชั่วคราว และอำนาจอัปเกรด ทุกตัวแปรเศรษฐกิจต้องมีเจ้าของ กฎการตรวจสอบ และการตอบสนองต่อค่าผิดปกติ

2. ขอบเขตของคอนแทรกต์และแอปพลิเคชัน

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

3. สถาปัตยกรรมข้อมูลและการจัดดัชนี

ข้อมูลในบล็อกเชนเป็นแบบ append-oriented ทำงานแบบไม่ประสานกัน และสามารถ reorganise ได้ ตัว indexer ต้องรองรับเหตุการณ์ซ้ำกัน, ธุรกรรม revert, การ reorganise ของ chain, ข้อมูลประวัติศาสตร์ที่ข缺หาย และความไม่สอดคล้องของ providers ยอดคงเหลือที่แสดงบนแดชบอร์ดควรสามารถ reconciliation กับสภาพบน chain ได้อย่างถูกต้อง

4. การปรับใช้และการอัปเกรด

การปรับใช้ในกระบวนการผลิตควรใช้สคริปต์ที่มีเวอร์ชัน การอนุมัติแบบหลายลายเซ็น การแยกสภาพแวดล้อม การติดตาม artefacts ที่เป็น deterministic และแผน rollback หรือหยุดชั่วคราว คอนแทรกต์ที่สามารถอัปเกรดได้ต้องมีมากกว่าตัว proxy อัปเกรด ต้องมีการควบคุมโดยการบริหาร จัดการ storage-layout และมีกระบวนการสื่อสารความเปลี่ยนแปลง

5. การทดสอบและการรับรอง

การทดสอบควรรวมถึง unit tests, invariant tests, integration tests, fork-based tests, fuzzing, static analysis, manual review และการฝึกสำหรับการปฏิบัติจริง กรอบความปลอดภัยของ NIST เช่น SP 800-218 เป็นแนวทางที่ดี ขณะที่แนวทางของ OWASP ช่วยโครงสร้างการวิเคราะห์ความเสี่ยงของแอปพลิเคชันและ API

แนวคิดด้านความปลอดภัย: การป้องกันที่มีประสิทธิภาพสูงสุดต่อความล้มเหลวของ Web3 คือไม่ใช่แค่การทำ audit เดียว เป็นการควบคุมเป็นชั้น— threat modelling, invariant testing, การปรับใช้โดยสิทธิ์น้อยที่สุด, การมอนิเตอร์ และการซ้อมรับมือเหตุการณ์—ซึ่งป้องกันไม่ให้สมมติฐานที่มองข้ามกลายเป็นความสูญเสียใน production

การรีวิวเหตุการณ์ในอดีตอธิบายให้เห็นว่าทำไมการใช้แนวทางหลายชั้นถึงสำคัญ Euler Finance สูญเสียประมาณ 197 ล้านดอลลาร์ ในเดือนมีนาคม 2023 หลังจากการโจมตีที่เกี่ยวข้องกับ logic การบริจาคและ liquidation เหตุการณ์นี้ไม่ใช่แค่ปัญหา frontend เท่านั้น แต่เป็นการเกี่ยวข้องของการบันทึกบัญชีโปรโตคอล, กระแส token, และการเปลี่ยนสถานะที่ควบคุมโดย attacker ในเดือนสิงหาคม 2021 Poly Network ประสบการโจมตีที่ประเมินมูลค่าประมาณ 611 ล้านดอลลาร์ ซึ่งเกี่ยวข้องกับข้อความ cross-chain และ logic การดำเนินการเชิงสิทธิพิเศษ

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

บริการ Web3 development และ security ของ Soken รวมการออกแบบสถาปัตยกรรม การส่งมอบแอปพลิเคชัน การรีวิวสมาร์ทคอนแทรกต์ การทดสอบ penetration และการรับรองโครงสร้างพื้นฐาน ความครอบคลุมที่เหมาะสมขึ้นอยู่กับว่าทำโปรเจกต์สำหรับสร้าง dapp ใหม่, การแก้ไขโปรโตคอล, การสร้างแดชบอร์ด หรือโปรเจกต์วิศวกรรมขนาดใหญ่

การสร้างแดชบอร์ดสำหรับ Web3 ทำงานอย่างไร?

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

แดชบอร์ดสำหรับโปรโตคอล DeFi จึงเป็นมากกว่า 페이지วิเคราะห์แบบธรรมดา มันอาจแสดงยอดรวมมูลค่ารวม (TVL) อัตราการใช้งาน, สัดส่วน collateral, การปล่อยรางวัล, ยอดคงเหลือ treasury, ข้อเสนอการปกครอง, ผลงาน validator, คิว liquidation หรือ ข้อความ cross-chain แต่ละตัวชี้วัดมีแหล่งที่มา ความถี่ในการอัปเดต ระดับความเชื่อมั่น และรูปแบบความล้มเหลวที่แตกต่างกัน

สถาปัตยกรรมแดชบอร์ดที่แนะนำ

1. แหล่งข้อมูลบล็อกเชน
   ใช้ RPC endpoint ที่เชื่อถือได้ เข้าถึง archive เมื่อมีความต้องการข้อมูลย้อนหลัง และใช้ event listener สำหรับคอนแทรกต์ที่เกี่ยวข้อง ยอดคงเหลือต้องตรวจสอบกับการอ่านตรงจากคอนแทรกต์หรือแหล่งข้อมูลอิสระ

2. การบูรณาการและปรับเป็นมาตรฐาน
   แปลงเหตุการณ์ดิบเป็นโมเดลภายในที่สอดคล้องกัน คำนึงถึงทศนิยม token, การอัปเกรดคอนแทรกต์, รหัส Chain ID, ที่อยู่ proxy และ schema ของเหตุการณ์ที่เปลี่ยนแปลง

3. ชั้น reconciliation
   เปรียบเทียบสถานะดัชนีกับสถานะบน chain ณ ช่วงเวลาที่กำหนด ชี้ความเบี่ยงเบนแทนที่จะเขียนทับโดยอัตโนมัติ

4. API และการควบคุมการเข้าถึง
   แยกข้อมูล analytics ที่เปิดเผยสาธารณะกับข้อมูลเชิงปฏิบัติการที่มีสิทธิพิเศษ ใช้การยืนยันตัวตน การอนุญาต การจำกัดอัตรา การบันทึก audit และการป้องกันการโจมตีแบบ injection หรือ DDoS

5. ส่วน frontend และการแจ้งเตือน
   แสดง timestamps, หมายเลขบล็อก, สถานะการยืนยัน และป้ายกำกับแหล่งข้อมูล การแจ้งเตือนสำคัญควรไปยัง operator ที่รับผิดชอบผ่านหลายช่องทาง

ประเภทแดชบอร์ดและลำดับความสำคัญในการออกแบบ

ประเภทแดชบอร์ด	ตัวชี้วัดสำคัญ	การควบคุมที่สำคัญ
โปรโตคอล DeFi	TVL, การใช้งาน, collateral, การ liquidate	ความสดของ oracle และ reconciliation
กระทรวงการคลัง	ยอดเงินคงเหลือ, การโอน, การอนุมัติ, การ vesting	การตรวจสอบ multisignature
การปกครอง	ข้อเสนอ, quorum, โหวต, สถานะการดำเนินการ	ความสอดคล้องระหว่าง snapshot กับการดำเนินการ
การดำเนินงานสะพาน	ข้อความ, validators, การยืนยัน, ความล่าช้า	การป้องกัน replay และแจ้งเตือนความผิดปกติ
ตลาด NFT	รายการ, ยอดขาย, royalty, ความเป็นเจ้าของ	ลำดับเหตุการณ์และความสมบูรณ์ของ metadata
กองกำลัง validator หรือ node	เวลาทำงาน, หน้าที่ที่พลาด, สุขภาพ peer	การ escalation ของการแจ้งเตือนและ redundancy

แดชบอร์ดไม่ควรแสดงความเชื่อมั่นว่าข้อมูลเป็นความจริง 100% หากข้อมูลพื้นฐานเป็น provisional เช่น รายการธุรกรรมในบล็อกที่อาจกลับรายการภายหลัง หรือข้อความ cross-chain ที่อาจยังไม่ได้รับการสรุปบนเครือข่ายอื่น ๆ คำป้าย เช่น “pending,” “confirmed,” “finalised,” และ “reconciled” เป็นการควบคุมการดำเนินงาน ไม่ใช่เพียงรายละเอียดภายนอก

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

หลังจากนิยามโมเดลข้อมูล ขั้นตอนถัดไปคือการรีวิวอิสระของแอปพลิเคชัน, คอนแทรกต์, API และโครงสร้างพื้นฐาน ทีมงานสามารถใช้ Security X-Ray ของ Soken สำหรับการประเมินความปลอดภัยเบื้องต้นก่อนแต่งตั้งการตรวจสอบเชิงลึก

คำแนะนำหลัก: หากผลิตภัณฑ์ของคุณอาศัยการโต้ตอบกับคอนแทรกต์ กระบวนการเชิงสิทธิ์ หรือข้อมูลบนบล็อกเชน ควรใช้ บริการ Web3 development, audit และ penetration testing ของ Soken เพื่อตรวจสอบสถาปัตยกรรมและการควบคุมการส่งมอบก่อนเปิดใช้งานใน production ความเสี่ยงก่อนหน้าที่เกี่ยวข้อง — การจัดการ reorganisations, การเข้าถึงสิทธิพิเศษ การ reconciliation และ governance การปรับใช้ — เป็นจุดที่การประเมินเชิงเทคนิคแบบบูรณาการให้คุณค่ามากกว่าการตรวจสอบเพียง frontend เท่านั้น

ควบคุมความปลอดภัยที่บริษัทพัฒนา Web3 ควรแสดงให้เห็น?

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

อย่างน้อยสุด คู่มือความปลอดภัยควรรวม:

• โมเดลภัยคุกคาม: สินทรัพย์, ผู้โจมตี, ขอบเขตความไว้วางใจ, กรณีการใช้งานที่ถูกตั้งใจใช้ผิด และความเสี่ยงที่เหลืออยู่
• รายการสิทธิ์: เจ้าของระบบ, ผู้ดำเนินการ, ผู้หยุดชั่วคราว, ผู้ดูแลการอัปเกรด, relayers, oracle, และบทบาทฉุกเฉิน
• บันทึกการทดสอบ: ครอบคลุม unit, integration, fuzz, invariant, fork, negative-path และ regression
• ทะเบียน dependency: ไลบรารีคอนแทรกต์ API RPC indexers สะพาน oracle และบริการคลาวด์
• การควบคุมการปรับใช้: การแยกสภาพแวดล้อม การอนุมัติแบบ multisignature การจัดการความลับ แฮช artefacts และ changelog
• แผนมอนิเตอร์: เหตุการณ์และเกณฑ์คะแนนสำหรับการถอนเงินผิดปกติ การเปลี่ยนแปลงบทบาท การเบี่ยงเบนของ oracle การทำธุรกรรมล้มเหลว และการหยุดให้บริการ
• การตอบสนองเหตุด่วน: ติดต่อ, ระดับ escalation, สิทธิ์หยุดชั่วคราว การเก็บรักษาหลักฐาน การสื่อสารกับผู้ใช้ และการตัดสินใจในการกู้คืน

การบริหารจัดการสิทธิ์ควรได้รับความสนใจเป็นพิเศษ คีย์การปรับใช้ใน production ควรไม่ควรถูกเก็บไว้บนแล็ปท็อปของนักพัฒนาคนเดียว และสิทธิ์ด้านการบริหารควรจำกัดตามบทบาทและขอบเขต การถูกฝังลึกของคีย์ validator ในเหตุกาณ์ Ronin แสดงให้เห็นว่าการรักษาความปลอดภัยทางปฏิบัติสามารถเอาชนะการออกแบบโปรโตคอลที่ซับซ้อนได้อีกด้วย

บริษัทควรอธิบายวิธีจัดการกับความล้มเหลวเฉพาะของ Web3 เช่น:

• การ reorganise ของ chain และความแตกต่างของความสุดท้าย
• การโจมตี replay ข้ามเครือข่าย
• การตั้งค่าของ chain ID ผิด และการแยก domain
• การละเมิดการอนุมัติ token
• การ staleness หรือการ manipulated ของ oracle
• การชนกันของ proxy storage
• ความแม่นยำและการเปรียบเทียบทศนิยมผิดพลาด
• การปฏิเสธการให้บริการผ่าน gas inputs ที่หนักหน่วง
• การเรียกภายนอกล้มเหลว และการดำเนินงานบางส่วน
• การหยุดชะงัก dependency และข้อจำกัดของอัตรา

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

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

ทีมงานสามารถบริหารจัดการการส่งมอบ การปฏิบัติตามกฎระเบียบ และการดำเนินงานในระยะยาวอย่างไร?

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

ลำดับการส่งมอบที่เป็นไปได้คือ:

1. กำหนดขอบเขตของผลิตภัณฑ์
   ระบุว่าสิ่งใดอยู่บน chain, นอก chain, เป็น custody, permissionless, permissioned หรือขึ้นอยู่กับ third party

2. บันทึกการตัดสินใจด้านสถาปัตยกรรม
   บันทึกการเลือก chain, การใช้ bridge, การอัปเกรดได้, การออกแบบ oracle, การจัดดัชนี, การรองรับวอลเล็ท และการเก็บข้อมูล

3. สร้างอัปเกรดที่ปลอดภัยที่สุด
   จำกัดฟังก์ชันการใช้งานและการเปิดเผยสินทรัพย์ในจุดเริ่มต้น หลีกเลี่ยงการเปิดตัวการทำงานร่วมกันที่ไม่ได้ทดสอบ เช่น governance, leverage, cross-chain messaging และ liquidity อัตโนมัติ

4. ทดสอบเชิงรุก
   ทดสอบ input ที่ไม่ถูกต้อง, token ที่เป็นอันตราย, ราคาที่ manipulated, บทบาทที่ถูกแฮก, ข้อมูลเก่า, RPC ที่ล้มเหลว และสภาพเครือข่ายผิดปกติ

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

6. ดำเนินงานและประเมินใหม่
   ตรวจสอบการแจ้งเตือน, กิจกรรมเชิงสิทธิพิเศษ, การเปลี่ยน dependency, รายงานของผู้ใช้ และสมมติฐานทางเศรษฐกิจหลังจากเปิดตัว

การปฏิบัติตามกฎระเบียบควรเริ่มต้นจากความเข้าใจด้านสถาปัตยกรรม โครงสร้างกฎหมาย ท่าเรือสินทรัพย์ สิทธิ์ใน token การควบคุมการลงโทษ การตลาด และเป้าหมายของลูกค้า ข้อมูลของ Soken Crypto Map ช่วยเปรียบเทียบภาพกฎระเบียบในระหว่างการวางแผนเขตอำนาจและตลาด

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

ศูนย์รวม Soken เป็นสถานที่กลางสำหรับสำรวจงานวิจัยและแนวทางเกี่ยวกับวิศวกรรม Web3, ความปลอดภัย และข้อควรระวังด้านกฎระเบียบ สำหรับโปรเจกต์ที่ซับซ้อนทางเทคนิค การจัดระเบียบข้อมูลเหล่านี้เป็นบันทึกการตัดสินใจภายในจะช่วยให้ผู้พัฒนารุ่นต่อไปเข้าใจว่าทำไมจึงเลือก chain, proxy, oracle หรือ data pipeline เฉพาะเจาะจง

คุณควรประเมินบริษัทพัฒนา dapp อย่างไร ก่อนเซ็นสัญญา?

คุณควรประเมินบริษัทพัฒนา dapp ผ่านการค้นพบเชิงเทคนิค, หลักฐานการส่งมอบที่เปรียบเทียบได้, แนวทางด้านความปลอดภัย, ข้อกำหนดการเป็นเจ้าของ และความพร้อมในการดำเนินงาน การเลือกบริษัทที่แข็งแกร่งที่สุดคือการผสมผสานระหว่างการทำแบบฝึกหัดด้านสถาปัตยกรรมเป็นลายลักษณ์อักษร กับการตรวจสอบตัวอย่างผลงาน แทนที่จะพึ่งพา pitch deck, prototype ภาพ หรือรายการเครือข่ายรองรับ

ใช้เช็คลิสต์การประเมินนี้:

ความสามารถทางเทคนิค

• บริษัทสามารถอธิบายวงจรธุรกรรมครบถ้วนได้ไหม?
• เข้าใจปัญหาเกี่ยวกับข้อผิดพลาดวอลเล็ท, ความขัดแย้ง nonce, การประมาณ gas, และความสุดท้ายของ chain หรือไม่?
• ออกแบบการจัดดัชนีและ reconciliation ได้หรือไม่? ไม่ใช่แค่หน้าจอ frontend เท่านั้น
• ทดสอบสิทธิ์เชิงสิทธิ์และ invariants ทางเศรษฐกิจหรือไม่?
• สามารถดำเนินระบบหลังจากปรับใช้แล้วหรือไม่?

ความครบถ้วนด้านความปลอดภัย

• ได้รวม threat modelling ก่อนเขียนโค้ดไหม?
• ผลการรีวิว audit ถูกติดตามผ่านการแก้ไขและการทดสอบซ้ำหรือไม่?
• Dependency และ third-party services ได้รับการบันทึกไหม?
• คีย์ใน production ถูกแยกและบริหารอย่างไร?
• การตอบสนองต่อเหตุการณ์เป็นส่วนหนึ่งของแผนการเปิดตัวหรือไม่?

ข้อกำหนดทางการค้าและการเป็นเจ้าของ

• ใครเป็นเจ้าของ repository, สคริปต์ปรับใช้, บัญชีโครงสร้างพื้นฐาน และเอกสาร?
• ใบอนุญาตโอเพนซอร์สและส่วนประกอบจาก third-party เปิดเผยหรือไม่?
• ระยะเวลาการสนับสนุนคือเท่าไร?
• คุณสมบัติการรับบริการด้าน Vulnerability ในระดับไหน?
• การย้ายเครือข่ายและการเปลี่ยนแปลงโปรโตคอลมีราคายังไง?

คุณภาพของผลิตภัณฑ์และการสื่อสาร

• ผู้ให้บริการจะท้าทายสมมติฐานด้านความปลอดภัยที่ไม่เหมาะสมไหม?
• จุดมุ่งหมายของ milestone เชื่อมโยงกับ acceptance criteria ที่สามารถทดสอบได้ไหม?
• ผู้มีส่วนได้ส่วนเสียที่ไม่ใช่ด้านเทคนิคจะเข้าใจความเสี่ยงอย่างชัดเจนไหม?
• ทีมแยกระหว่าง prototype กับระบบพร้อมใช้งาน production อย่างไร?

การฝึกที่ดีอีกอย่างคือการขอให้ผู้ให้บริการรายงาน 5 วิธีที่ผลิตภัณฑ์ที่เสนออาจล้มเหลว พร้อมลำดับความน่าจะเป็นและผลกระทบ ทีมงานที่มีวุฒิภาวะจะพูดคุยเกี่ยวกับสถานการณ์ที่ไม่สะดวกสบาย เช่น การหยุด oracle, Operator ที่ถูกคุกคาม, ทศนิยม token ผิด, ข้อมูลแดชบอร์ดล้าสมัย หรือล้มเหลวของการอัปเกรด โดยไม่ถือว่าคำถามเหล่านั้นเป็นอุปสรรคต่อการขาย

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

ก้าวสำคัญที่สุดคือการเตรียมระบบ boundary และ responsibility matrix หน้าหนึ่งก่อนเลือกผู้ให้บริการ ควรรวมสัญญา, วอลเล็ท, API,แดชบอร์ด, third parties, บทบาทเชิงสิทธิพิเศษ และกลุ่มเป้าหมายของผู้ใช้ จากนั้นขอให้ผู้สมัครแต่ละรายระบุเส้นทางความล้มเหลวที่มีผลกระทบสูงสุด