บทความนี้มาจาก a16z cryptoบทความนี้มาจาก

ผู้เขียนต้นฉบับ: Guy Wuollet เรียบเรียงโดยนักแปล Odaily Katie Gu

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

ชื่อเรื่องรอง

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

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

• นอกจากนี้ เป้าหมายควรอยู่รอบๆ โทเค็น แต่มักถูกมองข้าม ตัวอย่างเป้าหมายที่ชัดเจน ได้แก่

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

• โปรโตคอล DeFi หวังที่จะออกแบบโมเดลโทเค็นที่จัดสรรความเสี่ยงอย่างสมเหตุสมผลระหว่างผู้เข้าร่วม

• การออกแบบโปรโตคอลชื่อเสียงที่รับประกันเงินไม่สามารถแทนที่ชื่อเสียงได้โดยตรง (เช่น โดยแยกสภาพคล่องออกจากสัญญาณชื่อเสียง)

• ออกแบบเครือข่ายการจัดเก็บข้อมูลที่ช่วยให้ไฟล์พร้อมใช้งานโดยมีเวลาแฝงต่ำ

• ออกแบบเครือข่ายการปักหลักที่ให้ความปลอดภัยทางเศรษฐกิจสูงสุด

ออกแบบกลไกการกำกับดูแลที่กระตุ้นการตั้งค่าของผู้ใช้ที่แท้จริงหรือการมีส่วนร่วมสูงสุด

รายการดำเนินต่อไป ให้โทเค็นสนับสนุนกรณีการใช้งานใด ๆ และบรรลุเป้าหมายใด ๆ ไม่ใช่ในทางกลับกันแล้วคุณจะเริ่มกำหนดเป้าหมายที่ชัดเจนได้อย่างไร?

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

ลองใช้ EIP-1559 เป็นตัวอย่าง Roughgarden ระบุเป้าหมายที่ชัดเจนสำหรับ EIP-1559: "EIP-1559 ควรปรับปรุงประสบการณ์ของผู้ใช้ด้วยการประมาณการต้นทุนอย่างง่ายในรูปแบบของ 'การเสนอราคาที่ดีที่สุดที่ชัดเจน' นอกช่วงเวลาที่อุปสงค์เติบโตอย่างรวดเร็ว"

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

ชื่อเรื่องรอง

#2 ประเมินงานที่มีอยู่กับหลักการพื้นฐาน

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

ชื่อเรื่องรอง

# 3 ชี้แจงสมมติฐานของคุณ

อธิบายสมมติฐานของคุณอย่างชัดเจน เมื่อคุณมุ่งเน้นไปที่การสร้างโทเค็น เป็นเรื่องง่ายที่จะยอมรับสมมติฐานพื้นฐาน นอกจากนี้ยังง่ายต่อการบิดเบือนสมมติฐานที่คุณกำลังทำอยู่

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

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

ชื่อเรื่องรอง

#4 ตรวจสอบสมมติฐานของคุณ

มีคำกล่าวว่า "ไม่ใช่สิ่งที่คุณไม่รู้ที่ทำให้คุณมีปัญหา มันคือสิ่งที่คุณรู้แน่นอนว่าไม่ใช่"

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

ชื่อเรื่องรอง

#5 ชี้แจง "อุปสรรคที่เป็นนามธรรม"

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

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

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

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

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

ชื่อเรื่องรอง

#6 ลดการพึ่งพาพารามิเตอร์ภายนอก

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

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

ชื่อเรื่องรอง

# 7 ตรวจสอบสมมติฐานอีกครั้ง

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

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