โดย Kevin Tan, Co-Founder IOST
หลายคนถามผมว่า IOST ต้องการทำอะไรให้สำเร็จ และผมคิดว่า แท้จริงแล้วเป้าหมายของทีม R&D นั้นเรียบง่ายมาก นั่นคือ เราต้องการสร้างแพลตฟอร์มแอปพลิเคชั่นบล็อกเชนให้ดีกว่าเดิม เราจะมุ่งมั่นในการซ่อมแซมปัญหาที่มีอยู่ในเทคโนโลยีบล็อคเชนปัจจุบัน และหวังว่าจะได้พบทางออกในการบรรลุเป้าหมายที่เราเห็นว่าจำเป็นต่อแพลตฟอร์มแอปพลิเคชั่นบล็อกเชน ดังนั้นผมต้องการเริ่มต้นบทความนี้ด้วยปัญหาที่เราโฟกัส อธิบายถึงสิ่งที่เราจะทำ และเหตุผลของสิ่งเหล่านี้
1. สิ่งที่เราโฟกัส
หรือถ้าจะพูดให้ละเอียดกว่านี้คือ สิ่งที่เราพิจารณาตอนสร้าง IOST:
บล็อกเชนที่รองรับสัญญาอัจฉริยะสร้างคอมพิวเตอร์กระจายศูนย์ พร้อมกับระบบคอมพิวเตอร์และดาต้าที่น่าเชื่อถือ ขีดจำกัดของ “คอมพิวเตอร์” ดังกล่าวถูกกำหนดโดยศักยภาพการทำงานของมันเอง ยิ่งขีดจำกัดสูงเท่าไร เราก็ยิ่งสามารถรับรู้ประเภทที่แตกต่างกันของแอปพลิเคชั่นได้มากขึ้นเท่านั้น หากพูดให้เจาะจง ก็หมายความว่า เราสามารถจำแนกตัวบ่งชี้ประสิทธิภาพออกได้เป็น 3 ประเภท:
- Diverse High Throughput Rate
นี่เป็นตัวบ่งชี้ที่ได้รับการกล่าวถึงมากที่สุด และเป็นหนึ่งในมาตรฐานการวัดที่ใช้กันอย่างกว้างขวางที่สุดสำหรับบล็อกเชนยุคใหม่ อย่างไรก็ตาม ทีมR&D ไม่ได้โฟกัสในการทำให้ throughput rate เกิดประสิทธิภาพสูงสุดเพียงอย่างเดียว เพราะเรายังสร้างความมั่นใจในการแสดงผลที่เปี่ยมประสิทธิภาพสำหรับงานทุกรูปแบบ และในทุกสถานการณ์ (เช่น การโจมตี หรือการเชื่อมต่ออินเตอร์เน็ตที่ไม่มั่นคง ฯลฯ)
ในขณะเดียวกัน เราก็โฟกัสกับ throughput rate ของสัญญาเดี่ยวมากกว่า แทนที่จะดูว่าบล็อกเชนสามารถประมวลผลการดำเนินธุรกรรมได้มากเท่าไหร่ต่อวินาที ยกตัวอย่างเช่น เราสามารถดำเนินการโครงข่าย Ethereum สองแห่งในเวลาเดียวกัน ซึ่งทำให้เกิดโครงข่ายที่มี throughput rate เป็นสองเท่าของ Ethereum แต่เมื่อใช้สัญญาเดี่ยว ระบบคอมพิวเตอร์และสถานะของโครงข่ายนั้นแยกออกจากกัน การจัดสร้างระบบจึงสามารถเกิดขึ้นบนโครงข่ายเดี่ยวเท่านั้น ในกรณีนี้ throughput rate จึงไม่เพิ่มขึ้น
- ค่า Latency ต่ำ
ค่านี้มักหมายถึงเวลาระหว่างการเริ่มต้นการดำเนินธุรกรรมไปยังการยืนยัน และนี่ยังเป็นตัวบ่งชี้สำคัญที่เกี่ยวข้องกับประสิทธิภาพอีกด้วย แต่มักโดนมองข้าม ค่า latency ที่สูงขึ้นในโครงข่ายบล็อกเชนที่อิงการดำเนินธุรกรรมนั้นก็ยังพอทำงานได้ แต่สำหรับแพลตฟอร์มแอปพลิเคชั่นบล็อคเชนอย่าง IOST เราต้องการทำให้ค่า latency ต่ำลงมากที่สุด และเพิ่มศักยภาพความเร็วของ feedback
- เครื่อง Virtual Machines ที่มีประสิทธิภาพสูง
เวลาที่ใช้ในการทำงานลักษณะเดียวกันของเทคโนโลยี virtualization แต่ละแบบนั้นอาจมีความแตกต่างกันมาก อย่างที่กล่าวไว้ข้างต้นแล้วว่า ความคาดหวังสำหรับแพลทฟอร์มแอปพลิเคชั่นบล็อคเชนของเรานั้นไม่ได้หยุดที่การดำเนินธุรกรรมทั่วไปเท่านั้น ดังนั้น เราจึงไม่อาจหลีกเลี่ยงการเข้าไปจัดการกับสัญญาซับซ้อนหลายประเภท เราหวังว่าว่าเครื่อง virtual machine ที่เราเลือกจะทำงานอย่างมีประสิทธิภาพดีพอสำหรับการรับมือกับแอปพลิเคชั่นขนาดใหญ่จำนวนมาก และไม่ได้เพียงแต่โอ้อวดจำนวนการดำเนินการธุรกรรมแบบง่ายๆ เท่านั้น
แน่นอนว่าเรายังโฟกัสเรื่องการกระจายศูนย์และความปลอดภัยเป็นอย่างมากด้วย
- กระจายศูนย์มากกว่า EOS
การกระจายศูนย์เป็นรากฐานของความน่าเชื่อถือในบล็อกเชน เราจึงหวังว่าจะสามารถคง scale การจายศูนย์บางอันไว้เป็นรากฐานของการขยายตัว EOS เป็นจุดเริ่มต้นของแพลตฟอร์มแอปพลิเคชั่นบล็อกเชน และกลไกของ EOS DPOS ก็มุ่งมั่นในการสร้างความมั่นคงของโนด โดยไม่มีรางวัลให้กับผู้โหวต ในระหว่างที่่ความพยายามในการต่อต้านการติดศีลบนช่วยลดค่า
อินเซนทีฟสำหรับการเลือกตั้ง/การโหวต EOS คงความกระจายศูนย์ไว้ได้สูง โดยแทบไม่เหลือที่สำหรับการเปลี่ยนแปลง ในขณะเดียวกัน ถึงแม้ว่าปัญหาบางอย่างอาจแก้ไขได้ภายใต้การปกครองอย่างเข้มงวดของ EOS แต่ในเมื่อดาต้าบนบล็อกเชนสามารถถูกตัดเมื่อไหร่ก็ได้โดยองค์กร แนวคิดของบล็อกเชนจึงสูญเสียความบริสุทธิ์และเรียบง่ายบางประการไป เราหวังว่า IOST จะคงไว้ซึ่งบล็อกเชน และรักษาแก่นแท้ของบล็อกเชนไว้
- คงความมั่นคง
ความมั่นคงปลอดภัยเป็นรากฐานของบล็อคเชน และการสูญเสีย หรือการคอรัปชั่นของดาต้าเป็นสิ่งสุดท้ายที่เราอยากเห็นบนบล็อคเชนของเรา นี่เป็นเหตุผลว่าทำไมเราจึงต้องสร้างความมั่นใจว่า ความปลอดภัยบน IOST ของเราตรงกับบล็อคเชนสาธารณะแบบเมนสตรีมทั้งหมด
บล็อคเชนสาธารณะที่ดีก็เหมือนระบบการดำเนินงาน นอกจากการปฏิบัติงานที่มีคุณภาพแล้ว จะต้องสามารถเข้าถึงได้โดยผู้ใช้และนักพัฒนา
- การเข้าถึงที่ที่มีความยืดหยุ่นมากขึ้น และกลไกที่อัพเดท
เข้าถึงบัญชีและสัญญาที่กำหนดโดยฟังค์ชั่นที่มีความยืดหยุ่น คุณสามารถกลับไปยังระบบปลอมๆ ที่บ่งชี้ว่าไม่มีทางอัพเดทสัญญา หรือคุณสามารถสร้างโครงสร้างของสัญญาเพื่ออัพเดท ฟอร์ก หรือโรลแบ็ค ตราบเท่าที่คุณมีคุณสมบัติฟังค์ชั่นครบถ้วน ยกตัวอย่างเช่น คุณสามารถนิยามการเลือกตั้ง หรืออัพเดทโดยนักพัฒนาสำหรับ 3 วันแรก ซึ่งหมายความว่า IOST ได้สร้างความเป็นไปได้สำหรับการลงมติของนักพัฒนาในเลเวลสัญญา ทำให้สัญญานี้ร้ายกาจสุดๆ (หรือเปี่ยมไปด้วยพลัง)
- ค่าธรรมเนียมต่ำ หรือไม่มีเลยสำหรับผู้ใช้
ในระดับหนึ่ง EOS ตระหนักได้ถึงเป้าหมายของการไม่คิดค่าธรรมเนียม แต่ถึงอย่างนั้น ในบางครั้งมันก็แพงมากกว่าการใช้ หรือการพัฒนาบน Ethereum ซะอีก นอกจากนี้ ยังมีการสมัครลงทะเบียนเพิ่มมากขึ้น ซึ่งทำให้เกิดประสิทธิภาพต่ำในระบบนิเวศของบล็อกเชน จริงๆ แล้ว
นี่เกิดขึ้นจากกลไก EOS RAM เราหวังว่าบล็อกเชนที่มี throughput สูงจะสามารถทำให้ค่าใช้จ่ายต่ำลงโดยอัตโนมัติ และกลไกที่เราสร้างจะทำให้ทรัพยากรตกไปอยู่ในมือผู้ที่ต้องการจริงๆ เราต้องการทำให้มั่นใจว่าการใช้งาน การพัฒนาที่จ่ายไป และกลไกอื่นๆ สามารถนำไปใช้งานกับบล็อกเชนอื่นได้ด้วย
พัฒนาอย่างเฟรนด์ลี่
ระบบนิเวศของนักพัฒนาที่ไม่มีพิษภัยมีความหมายกับเราเป็นอย่างยิ่ง ดังนั้นเราจึงอยากสร้างแพลตฟอร์มที่ง่ายในการพัฒนาสำหรับนักพัฒนา ซึ่งรวมถึงปัจจัยดังต่อไปนี้:
ความปลอดภัย: มีปัญหาหลายข้อในเลเวลสัญญาของ Ethereum ที่นำไปสู่ปัญหาจริงจังตามมา และถึงแม้ว่าเราจะสามารถโทษความละเลยของนักพัฒนาได้ ในฐานะที่เราเป็นนักพัฒนาในบล็อกเชนสาธารณะ เราคิดว่าการตรวจสอบอย่างเคร่งครัดมากขึ้นจึงเป็นสิ่งสำคัญ และควรเพิ่มอินเตอร์เฟซที่เชื่อถือได้ เพื่อลดความเป็นไปได้ของความผิดพลาดสำหรับนักพัฒนา
โปรแกรมภาษา: เราต้องการใช้ภาษาที่ได้รับความนิยมและเข้าถึงได้ง่ายที่สุดสำหรับนักพัฒนา ดังนั้น C++ และ Haskall และภาษาที่คล้ายกันจึงจะได้รับการใช้เป็นภาษาเป้าหมายของเรา
เครื่องมือบุคคลที่สาม: เป้าหมายของเราอย่างหนึ่งคือ การปรับปรุงเครื่องมือนักพัฒนาของเราให้สมบูรณ์แบบอยู่อย่างต่อเนื่อง
2. แผนการพัฒนาของเรา
ด้วยการปล่อยตัว IOST Public Beta, Everest v0.5 ตัวแรกของเราในปลายเดือนมิถุนายน เราตระหนักได้ถึงเฟรมโครงข่ายบล็อกเชนที่เพรียบพร้อม และการตรวจสอบยืนยันขั้นต้นสำหรับ PoB ในขณะนี้ ทีมพัฒนาของเรากำลังเร่งพัฒนา public beta ตัวที่สองอย่างรวดเร็ว ด้วยรากฐานของ beta ตัวแรก เรากำลังดูเวอร์ชั่นเพิ่มเติมอีกสองแบบของ public beta และจะโฟกัสมากขึ้นเกี่ยวกับความสมบูรณ์แบบของ PoB ความมั่นคง ฟีเจอร์ใหม่ๆ โมเดลเศรษฐกิจ และการยืนยันของกลไกอื่นๆ หรือพูดอีกนัยหนึ่งก็คือ จากเวลาที่เหลืออยู่ในปีนี้ไปจนถึง Q1 ของปีหน้า เราจะโฟกัสในการทำให้โปรโตคอลที่เรียงลำดับในส่วนต่างๆ ของเชนภายในสมบูรณ์แบบ ตลอดปีหน้านี้ เราจะทำการค้นคว้าเกี่ยวกับทางออกของ off-chain scaling และการทำให้เทคโนโลยี sharding ประสบความสำเร็จ
ถ้าจะพูดเจาะจงให้มากขึ้น สิ่งที่คุณจะเห็นความสำเร็จใน public beta ตัวต่อไปมีดังนี้:
1. โค้ดโมดูลที่สมบูรณ์แบบ เพิ่มการปฏิบัติงานพื้นฐานและความมั่นคง
2. ระบบการเข้าถึงที่ใช้งานได้อย่างมีความยืดหยุ่น
3. รายละเอียดที่ได้รับการยืนยันมากขึ้นของ PoB
4. ข้อเสนอโมเดลเศรษฐกิจตัวแรก
5.หลังจากการจูนและทดสอบเครื่อง virtual machine แบบเมนสตรีมแล้ว เราตัดสินใจที่จะเคลื่อนเครื่อง virtual machine ไปยัง V8
6. แก้ไขปัญหาโนดที่เป็นภัยและการเสริมความปลอดภัยอื่นๆ
7. ปรับโครงสร้างโมดูลโครงข่าย P2P
8. การทำฟังค์ชั่นพื้นฐานที่ขาดหายไปให้สำเร็จ เช่น กลไกอีเวนท์ มีพอร์ท RPC เพิ่มเติม ฯลฯ
3. ทำไมเราจึงเลือกพัฒนาในรูปแบบนี้
ตามปกติแล้ว คำถามต่อมาคือ ทำไมเราจึงเลือก PoB เป็นทางออกสำหรับ scaling ของเรา และทำไมเราจึงพัฒนาตามเรทปัจจุบันของเรา ในตอนนี้ สำหรับทุกโปรเจคและการค้นคว้าในตลาด เรามักจะเห็นทางออกที่คล้ายกันอยู่ 4 อย่างสำหรับ scalability นั่นคือ การโหวต การ sharding DAG และ Layer2 (มักกล่าวถึงในนาม“off-chain”)
PoB คืออะไร และทำไมเราจึงเลือก PoB
สำหรับ IOST PoB เป็นสาขาของการโหวต ในอนาคต เราจะใช้ทางออกแบบ sharding และ off-chain เพื่อเสริม throughput rate ของระบบเราให้มากขึ้น
สิ่งที่ควรกล่าวถึงคือ ถึงแม้ว่า EOS DPoS จะค่อนข้างเป็นแบบกระจายศูนย์อยู่แล้ว มันก็ไม่ได้หมายความว่า การโหวตเป็นแบบกระจายศูนย์เสมอไป เพราะว่าสำหรับกลไกการลงมติแบบดั้งเดิมบางอัน ผู้นำคนเดียวเท่านั้นที่มีอำนาจในการผลิตดาต้าในวงจรเวลา DPoS เป็นเพียงทางออกวิธีหนึ่งภายใต้สาขา scalability ของการโหวตทั่วไป เราจึงสามารถกำหนดปริมาณของการกระจายศูนย์เป็นการแจกจ่ายของผู้ผลิตบล็อคภายในยูนิตหนึ่งของเวลา ทางออกที่เราเลือกใน beta ภายในใช้ทางออกแบบ layer 2 scaling
ถึงแม้ว่าเราจะเลือก PoB แต่ในการหลีกเลี่ยงการโจมตี Sybil เรายังใช้โมเดลแบบ pledge-plus-vote ในเลเยอร์แรก มันไม่ยากเลยที่จะพบว่าการการจัดสร้างและการป้องกันบล็อกเชนสาธารณะคือ สาขาของ PoW ไม่ก็ PoS เนื่องจากการเช่าพลังในการขุด (hash power) หรือโทเค่นยังเป็นกลไกการเข้าถึงเพื่อสร้างความมั่นคงให้กับบล็อคเชน รูปแบบอื่นของการลงมติยังคงเผชิญกับปัญหาความมั่นคง เช่น มีความเป็นไปได้ในการปลอมแปลงหรือไม่ ดาต้ามีความเป็นศูนย์กลางหรือไม่ สามารถตรวจสอบได้หรือไม่ว่า มติอิงดาต้าเกิดขึ้นภายในบล็อคเชน และไม่ใช่ off-chain โนดโครงข่ายใหม่สามารถเข้าร่วมในมติได้ไหม ฯลฯ นอกจากนี้ PoB ยังเป็นสาขาของ PoS ดังนั้น การเข้าเลเยอร์แรกจึงต้องใช้การยืนยันแบบอิงโทเค่น ซึ่งต้องใช้หลักประกันของโทเค่น และการสะสมของโทเค่นยืนยันจำนวนหนึ่ง ก่อนกลายเป็น “โนดที่เชื่อถือได้” และยืนยันให้เข้าร่วมมติได้
เลเยอร์ที่สองเป็นหัวใจของ PoB เนื่องจากว่าในเลเยอร์นี้ มีการเลือกการผลิตกรรมการบล็อค ในเลเยอร์นี้เรามุ่งหวังที่จะทำสองเป้าหมาย นั่นคือ
1.) กรรมการจะบังคับใช้การเปลี่ยนแปลงที่รวดเร็ว เพื่อการได้มาซึ่งการกระจายศูนย์ที่ดีขึ้น และ 2.) เราหวังว่าจะส่งเสริมโนดที่สร้างประโยชน์ให้กับโครงข่ายท่ามกลางการแข่งขันแบบเฟรนด์ลี่ ในการบรรลุเป้าหมายทั้ง สองอย่างที่กล่าวไว้ข้างต้น โนดทุกตัวจะได้รับคะแนน หรือ Servi ซึ่งสามารถสะสมผ่านการดำเนินธุรกรรมที่ได้รับการยืนยัน การดำเนินธุรกรรมที่จัดเป็นแพ็คเกจ และการกระทำโครงข่ายในรูปแบบนี้เท่านั้น
ในขณะเดียวกัน เหรียญที่ได้รับอนุญาตจะถูกแลกเปลี่ยนระหว่างวงจรเวลาทุกครั้ง ให้กลายเป็น Servi ตามจำนวนที่กำหนด ด้วยการผ่านการแข่งขันการบริโภค Servi นี้เท่านั้นที่จะให้โนดแข่งกันเป็นสมาชิกกรรมการที่เข้าร่วมมติ ในระหว่างที่โนดได้รับเลือกเข้าเป็นกรรมการจะได้รับ
โทเค่นรางวัลจากทุน นอกจากนี้ เราจะจัดการเลือกตั้งกรรมการบ่อยๆ ซึ่งจะทำให้เกิด 1.) สมาชิกกรรมการที่ได้รับการเลือกตั้งจะต้องบริโภค Servi เพื่อโนดที่ไม่ได้รับการเลือกตั้งจะได้รับคะแนนเพิ่มเติม และได้รับโอกาสได้การเลือกครั้งหน้า และ 2.) สมาชิกทุกรายจะต้องช่วยสร้างประโยชน์ให้กับโครงข่าย เพื่อให้รับ Servi เพิ่มขึ้น จึงทำให้โอกาสในการจัดวางโนดอินเซ็นทีฟเพิ่มขึ้น ด้วย EOS DPoD ซุปเปอร์โนดจะไม่ได้รับโทษจากการขาดความเคลื่อนไหว
การโหวตเป็นทางออกที่ตรงที่สุด และตอนนี้ก็เป็นการ scaling ที่เหมาะสมที่สุดสำหรับบล็อคเชนแอปพลิเคชั่นโฆษณาขนาดใหญ่ ไม่ว่าโนดจะได้เป็น “ซุปเปอร์” หรือไม่นั้น ไม่ใช่ปัจจัยที่สำคัญที่สุด แต่เป็นการหดตัว scale โครงข่ายลงเพื่อให้ได้มาซึ่งมติที่รวดเร็วขึ้น และส่งเสริมให้โนดเพิ่มประสิทธิภาพระบบคอมพิวเตอร์เพื่ออินเซ็นทีฟที่เพิ่มขึ้น
- ขั้นตอนที่สอง — ทางออกแบบ Off-Chain กับ Sharding
ไม่ว่าจะเป็น Lightning Network, Ethereum Plasma หรือเทคโนโลยีใหม่ๆ โฟกัสทั่วไปได้เคลื่อนที่จากการเก็บดาต้าทั้งหมดบนบล็อคเชน ไปยังการค่อยๆ แก้ปัญหา off-chain นี่คือหนึ่งในเส้นทางหลักที่เรากำลังมุ่งหน้าไปสู่สำหรับขั้นตอนที่สอง เราหวังว่าทางออกสำหรับ off-chain scaling จะสามารถแก้ปัญหา scalability ในบางสถานการณ์ได้ ยกตัวอย่างเช่น การประมวลผลหุ้นขนาดเล็กของดาต้าที่มีความปลอดภัยต่ำ อย่างไรก็ตาม สิ่งที่เราควรทราบคือ off-chain scaling ไม่ได้มีพลังมากเสมอไป การสูญหายของดาต้าอาจนำไปสู่ปัญหาจริงจังที่ตามมาได้ ดังนั้น จึงควรทำการประมวลผลบนบล็อคเชนหลักเหมือนเดิม ในระดับโค้ดดิ้ง โมเดลประกันทั่วไปไม่สามารถชดใช้ผู้ใช้ที่ต้องประสบกับการสูญเสียอย่างมาก และไม่สามารถเทียบเคียงกับมูลค่าที่แท้จริงของดาต้าได้ด้วย เรามองทางออก off-chain เป็นทางออก scaling ที่สอง หลังจากการทำให้บล็อกเชนหลักของเราสมบูรณ์แล้ว
Sharding เป็นทางออก scaling โปรโตคอลอิง PoB ที่เรียงลำดับเช่นกัน ในอัตราการพัฒนาปัจจุบันของเรา เรามองข้อนี้เป็นทางออกที่สองเหมือนกัน ถึงแม้ว่าเราได้ทำการค้นคว้าและทดสอบเทคโนโลยี sharding หลายครั้งแล้ว ไม่ว่าจะเป็นทางออกหรือโฆษณา ปัญหาที่เลี่ยงไม่ได้เลยคือ การที่เราต้องแยกส่วนโครงข่าย แม้ว่านี่จะส่งผลออกมาเป็นตัวเลขที่น่าพอใจ แต่มันจะลดความปลอดภัยลงอย่างน่าตกใจ ผู้ใช้โครงข่ายบล็อคเชนจะต้องสะสมอย่างต่อเนื่อง ตอนแรกที่เราปล่อยตัว เราต้องการให้ IOST คงความบริสุทธิ์/ความเรียบง่าย ในขณะที่รักษาความปลอดภัยและมั่นคงไว้ PoB อย่างเดียวนั้นเพียงพอแล้วสำหรับช่วงแรก ในขณะที่เทคโนโลยี sharding จะยังคงทำงานและได้รับการอัพเดทบนโครงข่าย beta ของเรา
ทำไมเราถึงไม่ใช้ DAG
เราได้ทำการค้นคว้ามากมายเกี่ยวกับเทคโนโลยีที่เกี่ยวข้องกับ DAG ในปัจจุบัน และในขณะนี้ ก็ยังไม่มีทางออกที่ค่อนข้างมั่นคงและมีแบบแผน นอกจากนี้ ยังมีอีกสองสาเหตุที่เราไม่เลือก หรือทำวิจัยโครงสร้าง DAG นั่นคือ 1.) DAG ต้องทิ้งการทำงานสม่ำเสมอที่เข้มแข็ง ทำให้เกิดค่า latency ที่สูงขึ้นอย่างเลี่ยงไม่ได้ ซึ่งไม่ตรงกับคุณสมบัติของเป้าหมายเรา และ 2.) DAG จัดลำดับภายใต้ความสม่ำเสมอในตอนท้าย ซึ่งสามารถนำไปสู่การ overload ของระบบคอมพิวเตอร์สำหรับโนด ในสถานการณ์หนักๆ ได้
4. บทสรุป
สำหรับเรา เทคโนโลยีบล็อกเชนยังถือว่าอยู่ในขั้นเริ่มต้น ดังนั้น นอกจากการอภิปรายเกี่ยวกับการลงมติอยู่อย่างสม่ำเสมอ มันยังมีอีกหลายด้านที่ต้องการความสมบูรณ์แบบ บทความนี้ถูกเขียนขึ้นด้วยความหวังที่จะให้ผู้ที่มีความสนใจใน IOST หรือเทคโนโลยีบล็อกเชนทราบสิ่งที่เรากำลังทำ เราหวังว่า IOST จะสามารถกลายเป็นแพลตฟอร์มแอปพลิเคชั่นบล็อกเชนที่สามารถนำไปใช้ในงานขนาดใหญ่ได้ อย่างไรก็ตาม ด้วยคำที่จำกัดของบทความนี้ เราจึงไม่สามารถอธิบายถึงรายละเอียดทางเทคนิคอีกหลายอย่างที่เราได้ยืนยัน พร้อมทั้งการพัฒนาและนวัตกรรมอีกมากมายที่เราสร้างขึ้นทั้งหมดได้ ในช่วงเดือนต่อไปนี้ คุณจะได้ค่อยๆ ทำความรู้จักกับนักวิจัย
แถวหน้าของเรา และพวกเขาจะได้อธิบายถึงรายละเอียด ดีไซน์เฉพาะตัว และทางออกเพิ่มเติมสำหรับการพิจาณาของเรา