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

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

หลักการที่เราแบ่งปันที่นี่มีผลกับแอปพลิเคชัน web3 ทั้งหมด - ตั้งแต่ DeFi ไปจนถึงแอปพลิเคชันโซเชียลที่ไม่มีการกำหนด PIN และทุกที่ที่อยู่ระหว่างนั้น

อุปสรรคสำหรับโมเดลโทเค็น

โทเคนโครงสร้างมีการผูกพันต่อการของขวัญและความต้องการซึ่งเมื่อความต้องการเพิ่มขึ้น จำนวนการจัดหาก็ลดลงและตลาดจึงปรับตัวตามนั้น พื้นฐานเศรษฐศาสตร์เชิงพื้นเมืองสำหรับโทเคนโครงสร้างหลายรายการถูกเร่งความเร็วโดย Ethereum Improvement Proposal 1559 (EIP-1559), ซึ่งได้นำเสนอค่าธรรมเนียมหลักที่จะถูกเผาสำหรับการทำธุรกรรม Ethereum ทั้งหมด แต่ถึงแม้จะมีการพยายามซื้อและเผารุ่นบางส่วน แต่ยังไม่มีรุ่นเทียบเท่ากับ EIP-1559 สำหรับโทเคนในแอปพลิเคชัน

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

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

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

โซลูชั่นของเราเน้นการแก้ปัญหาสามปัญหาที่เกิดขึ้นกับโทเคนแอปพลิเคชั่นที่เกี่ยวข้องกับ:

1. ความท้าทายในการปกครอง
2. ความท้าทายในการกระจายค่า
3. ความท้าทายกับกิจกรรมที่ได้รับการกำกับดูแล

1. ความท้าทายในการบริหาร

โทเค็นแอปพลิเคชันมักมีสิทธิ์ในการปกครอง และการมีองค์กรอัตโนมัติแบบกระจาย (DAO) สามารถเป็นปัจจัยที่เข้ามาเพิ่มขึ้นความไม่แน่นอน ที่โทเค็นโครงสร้างพื้นฐานไม่เผชิญ สําหรับ DAOs ที่มีการดําเนินงานในสหรัฐอเมริกาอย่างมีนัยสําคัญความเสี่ยงอาจเกิดขึ้นหาก DAO สามารถควบคุมรายได้จากโปรโตคอลหรือตัวกลางกิจกรรมทางเศรษฐกิจของโปรโตคอลและทําให้กิจกรรมดังกล่าวเป็นโปรแกรม เพื่อหลีกเลี่ยงความเสี่ยงเหล่านี้โครงการสามารถกําจัดการควบคุมที่ DAO มีโดยการลดการกํากับดูแล สําหรับ DAOs ที่เป็นไปไม่ได้ไวโอมิงใหม่ของไวโอมิง Decentralized Unincorporated Nonprofit Association (DUNA)ให้aEntity ทางกฎหมายที่เป็นแบบกระจายที่อาจช่วยลดความเสี่ยงเหล่านี้และปฏิบัติตามกฎหมายภาษีที่เกี่ยวข้อง

2. ความท้าทายในการกระจายมูลค่า

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

โครงการควรสำรวจโดยที่แทนทางไปทางส่วนของกิจกรรมการค้า— การตอบแทนผู้ถือโทเค็นสำหรับการมีส่วนร่วมในโครงการอย่างที่เป็นประโยชน์ต่อโครงการ มีโครงการอีกมากมายที่ส่งเสริมให้มีส่วนร่วมที่เป็นบวก, รวมถึงการดำเนินการฝั่งหน้า(Liquity), ร่วมรับส่วนร่วมในโปรโตคอล (Goldfinch), และมอบหลักทรัพย์เป็นส่วนหนึ่งของโมดูลความปลอดภัย (Aave). ที่นี่มีพื้นที่ในการออกแบบอย่างกว้างขวาง แต่สถานที่ที่ดีที่จะเริ่มต้นคือการกำหนดผังผู้มีส่วนได้สัมพันธ์ทั้งหมดในโครงการ กำหนดว่าควรส่งเสริมพฤติกรรมใดจากแต่ละฝ่ายและตัดสินใจว่าโปรโตคอลสามารถสร้างค่ารวมที่สำคัญผ่านการสร้างสิทธิแบบนั้นได้

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

3. ความท้าทายกับกิจกรรมที่ได้รับการควบคุม

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

วิธีการแนะนำที่เสนอข้อสรุปในปัญหานี้มุ่งเน้นการ จำกัดการรวมมูลค่ากิจกรรมเพื่อให้เป็นไปตามกฎหมายในสหรัฐฯ - เช่นเปิดค่าธรรมเนียมโปรโตคอลเฉพาะกับสระว่ายน้ำความเป็นไปได้บางประการ สิ่งนี้ทำให้โครงการเกี่ยวกับพื้นที่สุดยอดของการกำกับดูแลที่ต่ำที่สุดและทำลายข้อเสนอค่าของโปรโตคอลโลกที่เป็นอัตโนมัติ นอกจากนี้ยังเป็นการทำลายส่วนหน้าที่ของการลดการบริหารจัดการ การกำหนดว่ายกเว้นใดๆในการเรียกเก็บค่าธรรมเนียมที่จะทำงานได้จากมุมมองการปฏิบัติตามกฎหมายไม่ใช่งานที่เหมาะสมสำหรับ DAOs.

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

หนึ่งปัญหาหลัก: การติดตามค่าธรรมเนียม

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

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

ขั้นตอนที่ 1: การระบุว่าฟีซเกิดจากฟรอนต์เอ็นด์ไหน และ

ขั้นตอนที่ 2: นำค่าธรรมเนียมไปเป็นส่วนต่าง ๆ ของพูลต่าง ๆ โดยใช้ตัวตัดสินใจที่กำหนดเอง

การทำแผนที่ด้านหน้า

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

ค่าธรรมเนียมการเสถียร

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

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

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

การติดตามค่าธรรมเนียมผ่านกระบวนการคัดเลือก

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

App.xyz สามารถปฏิบัติตามกฎการปฏิบัติตามข้อกําหนดเฉพาะสําหรับเขตอํานาจศาลที่ตั้งอยู่ กิจกรรมแอปพลิเคชันที่มาจาก app.xyz สร้างค่าธรรมเนียมโปรโตคอล App.xyz มีโมดูลการปักหลักของตัวเอง และผู้ถือโทเค็นสามารถเดิมพันโทเค็นของตนไปยังโมดูลนั้นได้โดยตรงหรือไปยังภัณฑารักษ์ที่ต้องการเลือกตะกร้าส่วนหน้าที่พวกเขาเห็นว่าสอดคล้องกัน ผู้เดิมพันโทเค็นเหล่านี้จะได้รับผลตอบแทนในรูปแบบของค่าธรรมเนียมจากชุดของส่วนหน้าที่พวกเขาเดิมพัน หากส่วนหน้าสร้างค่าธรรมเนียม $100 และ 100 เอนทิตีแต่ละโทเค็นปักหลัก 1 โทเค็น แต่ละเอนทิตีจะมีสิทธิ์ได้รับ $1 ภัณฑารักษ์สามารถเรียกเก็บค่าธรรมเนียมสําหรับบริการของพวกเขาในขั้นต้น ในอนาคตรัฐบาลสามารถรับรอง onchain เกี่ยวกับ frontends ที่ปฏิบัติตามในเขตอํานาจศาลของตนเพื่อช่วยปกป้องผู้บริโภคโดยประโยชน์เสริมคือระบบอัตโนมัติของการดูแลรักษา

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

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

จากทฤษฎีสู่การนำไปใช้จริง: การนำวิธีใช้งานในปฏิบัติ

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

1. ส่วนหน้าหรือ API แต่ละรายการสามารถเพิ่มระเบียน TXT พิเศษลงในระเบียน DNS ของโดเมนได้ เช่น ENS DNS integration. บันทึก TXT นี้มีคีย์สาธารณะของคู่คีย์หนึ่งที่เฟรอนท์เอนด์สร้างขึ้นหนึ่งครั้งเท่านั้นที่เรียกว่าใบรับรอง

1. ไคลเอนต์ฝั่งหน้าสามารถเรียกใช้ฟังก์ชัน register() และพิสูจน์ว่าเป็นเจ้าของชื่อโดเมนของตัวเอง การจับคู่ระหว่างโดเมนกับคีย์สาธารณะของใบรับรอง และกลับกัน ถูกจัดเก็บ
2. เมื่อธุรกรรมถูกสร้างขึ้นผ่านไคลเอ็นต์ มันยังเซ็นชื่อเซิร์ติฟิเคตภายในธุรกรรมด้วยคีย์สาธารณะใบรับรอง สิ่งเหล่านี้จะถูกส่งให้กับสัญญาอัจฉริยะของแอปพลิเคชันเป็นกลุ่ม
3. สัญญาอัจฉริยะของแอปพลิเคชันยืนยันใบรับรอง ตรวจสอบว่ามันสอดคล้องกับร่างกาย tx ที่เหมาะสม และได้รับการลงทะเบียนแล้ว หากใช่ ธุรกรรมจะถูกดำเนินการ ค่าธรรมเนียมที่สร้างโดยธุรกรรมจะถูกส่งไปยังสัญญา FeeCollector พร้อมกับชื่อโดเมน (จากทะเบียน)
4. FeeCollector ช่วยให้ผู้กำกับ, ผู้ใช้, ผู้ตรวจสอบ, และผู้อื่น ๆ สามารถเดิมพันโทเค็นโดยตรงกับโดเมนหรือชุดโดเมนได้ เหล่าสัญญาเหล่านี้ต้องเก็บบันทึกจำนวนโทเค็นที่เดิมพันในแต่ละโดเมน ส่วนแบ่งของที่อยู่ของแต่ละที่อยู่ในการเดิมพันนั้น ๆ และจำนวนเวลาที่พวกเขาเดิมพันไปแล้ว การนำไปใช้ร่วมกันอย่างน่าสนใจของการขุดเหมืองเหรียญสามารถนำมาใช้เป็นจุดเริ่มต้นสำหรับตรรกะสัญญานี้ได้
5. ผู้ใช้ที่ได้ทำการเดิมพันกับผู้ดูแล (หรือโดยตรงกับสัญญาการจัดการค่าธรรมเนียมเอง) สามารถถอนส่วนแบ่งค่าธรรมเนียมตามจำนวนแอปท็อกเค็นที่เดิมพันกับโดเมนได้ โครงสร้างอาจเป็นที่คล้ายกันกับ MetaMorpho/Morpho Blue.

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

ข้อคิดเกี่ยวกับการใช้งานเพิ่มเติม โดยอิงจากประเภทของแอปพลิเคชัน

ในขณะที่หลักการเหล่านี้ใช้กับโมเดลเศรษฐศาสตร์โทเคนในการประยุกต์อย่างกว้างขวาง อาจมีการพิจารณาค่าธรรมเนียมอื่นๆ อย่างตามประเภทของแอปพลิเคชั่น: แอปที่สร้างขึ้นบนเลเยอร์ 1 หรือเลเยอร์ 2, แอปเชน, และแอปที่สร้างขึ้นโดยใช้ rollups

คำนึงถึงการใช้งาน L1/ L2

แอปพลิเคชันบนบล็อกเชนเลเยอร์ 1 หรือเลเยอร์ 2 มีสัญญาอัจฉริยะที่ปรับใช้โดยตรงบนเชน ค่าธรรมเนียมจะถูกเรียกเก็บเมื่อผู้ใช้โต้ตอบกับสัญญาอัจฉริยะของแอปพลิเคชัน โดยปกติจะเกิดขึ้นผ่านส่วนหน้าที่ใช้งานง่าย (เช่นแอปหรือเว็บไซต์) ที่ทําหน้าที่เป็นอินเทอร์เฟซระหว่างผู้ใช้รายย่อยและสัญญาอัจฉริยะพื้นฐาน ในกรณีนั้นค่าธรรมเนียมใด ๆ จะเกิดขึ้นกับส่วนหน้านั้น ตัวอย่างข้างต้นเกี่ยวกับ app.xyz แสดงให้เห็นว่าระบบค่าธรรมเนียมสามารถทํางานกับแอปเลเยอร์ 1 ได้อย่างไร

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

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

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

ทางค่าธรรมเนียมจะสะท้อนตัวอย่างที่ให้มาในส่วนที่แล้ว

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

ข้อคิดที่ต้องพิจารณาสำหรับ appchains

Appchains เป็นเทคโนโลยีบล็อกเชนที่เฉพาะเจาะจงสำหรับแอปพลิเคชันที่มีผู้ตรวจสอบที่ทำงานเฉพาะสำหรับแอปพลิเคชันนั้นเท่านั้น

เป็นการแลกเปลี่ยนกับงานของพวกเขา ผู้ตรวจสอบเหล่านั้นจะได้รับการชำระเงินเป็นค่าตอบแทน ต่างจากบล็อกเชนชั้นที่ 1 ที่ผู้ตรวจสอบมักได้รับรางวัลผ่านการออกจำหน่ายโทเค็นในรูปแบบที่เพิ่มขึ้น บางแอปเชน (dYdX) แทนที่จะส่งค่าธรรมเนียมลูกค้าให้กับผู้ตรวจสอบ

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

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

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

คำนึงถึงการใช้งานของ Application Rollups

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

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

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

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

คำปฏิเสธ：

1. บทความนี้พิมพ์ซ้ําจาก [a16zcrypto]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Mason HallPorter SmithMiles Jennings and Ross Shuel]. หากมีคำประทับใจต่อการเผยแพร่ฉบับนี้ กรุณาติดต่อGate Learnทีมงานจะดูแลและจัดการกับมันโดยรวดเร็ว
2. คำประกาศความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้นและไม่เป็นที่เป็นการให้คำแนะนำเกี่ยวกับการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นๆ โดยทีม Gate Learn ถูกดำเนินการ นอกจากที่ระบุไว้ การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถูกห้าม