20% ของรายได้ใช้สำหรับการเผา: ICP Cloud Engine สามารถรองรับการประเมินมูลค่าโทเคนใหม่ได้หรือไม่?

ผู้เขียนต้นฉบับ: เสี่ยวปิ่ง

ในช่วงสุดสัปดาห์ ชุมชน ICP เกิดความคึกคักขึ้นมาทันที จุดสนทนาคือ Cloud Engines ผลิตภัณฑ์ที่ให้องค์กรสามารถรันซับเน็ตส่วนตัวบน Internet Computer ได้

เหตุผลที่คึกคักนั้นตรงไปตรงมา: DFINITY ผูก Cloud Engines เข้ากับแผนลดปริมาณอุปทานที่ชื่อ Mission 70 ผู้ให้บริการโหนดขาย Cloud Engines ให้องค์กร รายได้ 80% เป็นของตัวเอง อีก 20% ส่งให้เครือข่ายไปซื้อ ICP และเผาทิ้ง หากมีลูกค้าองค์กรมากพอ อัตราเงินเฟ้อของ ICP จะลดจาก 9.72% เหลือ 2.92% คิดเป็นการลดลง 70%

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

คำถามคือ เรื่องราวนี้อยู่ในระยะไหนในตอนนี้?

Cloud Engines คืออะไรกันแน่?

ลองจินตนาการว่า Cloud Engines คือ "ศูนย์ข้อมูลแบบสั่งทำ"

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

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

ผู้ให้บริการโหนดนำฮาร์ดแวร์ของตัวเองขึ้นตลาดผ่าน opencloud.org กรองตามที่ตั้งทางภูมิศาสตร์ ข้อกำหนด และระยะเวลาการทำงาน องค์กรเลือกโหนดบนนั้น ประกอบซับเน็ตของตัวเอง เริ่มต้นขั้นต่ำ 4 โหนด

ฟังดูในอุดมคติ แต่มีรายละเอียดบางอย่างที่ต้องสังเกต

ระยะห่างระหว่างเรื่องเล่ากับความเป็นจริง

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

แต่โหนด SEV ยังไม่มีอยู่ในปัจจุบัน

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

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

กรณีที่เกิดขึ้นจริงแล้วได้แก่ Pakistan National Cloud Engine และโครงการนำร่องของ UNDP ChatT ของปากีสถาน ซึ่งเป็นแอปสื่อสารอธิปไตย ได้เข้าสู่ระยะเผยแพร่แล้ว กรณีเหล่านี้พิสูจน์ว่าผลิตภัณฑ์ใช้งานได้ แต่ยังห่างจาก "การนำไปใช้ในองค์กรขนาดใหญ่" อย่างชัดเจน

ในเอกสารไวท์เปเปอร์ของ Mission 70 มีตัวเลขสำคัญชุดหนึ่ง

อัตราการเผา cycle ของ ICP ในปัจจุบันอยู่ที่ประมาณ 0.0689 TCYCLES/s หากต้องการบรรลุเป้าหมายลดอุปทาน 70% ตัวเลขนี้ต้องสูงถึง 0.77 XDR/s ซึ่งประมาณ 15 เท่าของปัจจุบัน

Mission 70 แยกการลดเงินเฟ้อออกเป็นสองขา: ด้านอุปทานตัดรางวัลโหนด contributed 44% ของการลดลง; ด้านอุปสงค์พึ่งพาการเพิ่มการเผา ต้อง contributed 26% ที่เหลือ มาตรการด้านอุปทานค่อนข้างควบคุมได้ เช่น ตัดรางวัลโหนดรุ่นแรก 40% ลดจำนวนโหนดขั้นต่ำของซับเน็ตจาก 13 เหลือ 7 สิ่งเหล่านี้เป็นการตัดสินใจที่การลงคะแนน治理ทำได้

แต่ด้านอุปสงค์ขึ้นอยู่กับตลาดทั้งหมด 20% ของรายได้ Cloud Engines ต้องแปลงเป็นปริมาณการเผา ICP ที่เพียงพอ เงื่อนไขคือรายได้ของ Cloud Engines ต้องมีขนาดใหญ่พอ ในฐานการเผาปัจจุบันที่ 6,000 ดอลลาร์ต่อวัน ต้องเติบโตจากใกล้ศูนย์ไปสู่การเผาเพิ่มหลายหมื่นดอลลาร์ต่อวัน เพื่อให้ขานี้ยืนขึ้นได้

ท่าทีของนักวิเคราะห์คนหนึ่งบน Reddit เป็นตัวแทนที่ดี: เขามอง ICP ในระยะยาวในแง่บวก แต่ต่อการบรรลุเป้าหมาย 70% ภายในปี 2026 เขาถือจุดยืน "พิสูจน์ก่อนแล้วค่อยว่ากัน" เขาเห็นว่าต้องเห็นอัตราการเผา cycle ทรงตัวที่ 0.3 ถึง 0.5 TCYCLES/s อย่างต่อเนื่อง จึงจะเชื่อว่าแนวโน้มนี้เป็นจริง

มองไพ่ใบนี้อย่างไร?

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

แต่จากมุมมองการลงทุน มีปัญหาช่องว่างของเวลาอยู่ตรงนี้

เรื่องเล่าวิ่งนำหน้าผลิตภัณฑ์ กลไกการเผา 20% ถูกชุมชนพูดคุยในฐานะตรรกะหลักของการประเมินค่าโทเคนใหม่แล้ว แต่ Cloud Engines ยังเพิ่งเริ่ม Early Access เท่านั้น โหนดเข้ารหัส SEV ยังอยู่ในโรดแมป ปริมาณการเผารวมต่อวันยังไม่ถึงหนึ่งหมื่นดอลลาร์ โทเคนร่วงจากจุดสูงสุดแล้ว 99.6% มูลค่าตลาดถูกบีบเหลือ 1.1 พันล้านดอลลาร์ การประเมินมูลค่าถูกจริง

ทุกขั้นตอนบนเชนนี้ต้องใช้เวลา: Cloud Engines จาก Early Access ถึงการใช้งานเชิงพาณิชย์อย่างเป็นทางการ ลูกค้าองค์กรจากนำร่องถึงการจัดซื้อในขนาด lớn ผู้ให้บริการโหนดจากไม่กี่รายถึงการเกิดตลาดแข่งขัน การแบ่งรายได้ 20% จากกลไกบนกระดาษถึงการเกิดปริมาณการเผาที่มีความหมายจริง

มาตรการด้านอุปทานของ Mission 70 ตัดรางวัลโหนด ลดขนาดซับเน็ต เป็นตัวเร่งที่ใกล้กว่า หากข้อเสนอการ治理เหล่านี้เกิดขึ้นในอีกไม่กี่เดือนข้างหน้า อัตราเงินเฟ้อจะลดลงเป็นขั้นบันได ซึ่งส่งผลต่อราคาในระยะสั้นโดยตรงกว่า Cloud Engines

ส่วนเรื่องราวของ Cloud Engines เป็นการเดิมพันที่ไกลกว่า เดิมพันว่า ICP จะตัดส่วนเล็ก ๆ จากตลาดคลาวด์คอมพิวติ้งมูลค่าล้านล้านดอลลาร์ได้ และรายได้จากส่วนเล็ก ๆ นี้เพียงพอที่จะทำให้อัตราการเผา 20% สร้างแรงกดดันด้านการลดอุปทานที่แท้จริง

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

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