เป็นไปได้ไหมที่จะสุ่มตัวเลขหากเราไม่ไว้ใจกัน? ส่วนที่ 1

เฮ้ ฮับ!

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

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

เมื่อเราออกแบบโปรโตคอลการสร้างตัวเลขสุ่มแบบกระจาย เราต้องการให้มีคุณสมบัติสามประการ:

1. เขาจะต้องเป็นกลาง กล่าวอีกนัยหนึ่ง ผู้เข้าร่วมไม่ควรมีอิทธิพลต่อผลลัพธ์ของเครื่องสร้างตัวเลขสุ่มในทางใดทางหนึ่ง

2. เขาจะต้องคาดเดาไม่ได้ กล่าวอีกนัยหนึ่ง ผู้เข้าร่วมไม่ควรสามารถคาดเดาได้ว่าจำนวนใดจะถูกสร้างขึ้น (หรืออนุมานคุณสมบัติใดๆ ของมัน) ก่อนที่จะถูกสร้างขึ้น

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

ในบทความนี้เราจะดูสองวิธี: RANDAO + VDF และวิธีลบรหัส ในส่วนถัดไป เราจะตรวจสอบรายละเอียดวิธีการตามลายเซ็นเกณฑ์

แต่ก่อนอื่น เรามาดูอัลกอริธึมที่เรียบง่ายและใช้กันทั่วไปซึ่งทำงานได้ คาดเดาไม่ได้ แต่มีอคติ

รานดาว

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

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

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

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

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

รันดาว+วีดีเอฟ

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

(vdf_output, vdf_proof) = VDF_compute(input) // это очень медленно
correct = VDF_verify(input, vdf_output, vdf_proof) // это очень быстро

ฟังก์ชันนี้เรียกว่าฟังก์ชัน Verifiable Delay หรือ VDF หากการคำนวณผลลัพธ์สุดท้ายใช้เวลานานกว่าขั้นตอนการเปิดเผยหมายเลข ผู้โจมตีจะไม่สามารถคาดเดาผลของการแสดงหรือซ่อนหมายเลขของเขาได้ ดังนั้นเขาจะสูญเสียโอกาสในการกำหนดผลลัพธ์

การพัฒนา VDF ที่ดีนั้นยากมาก มีความก้าวหน้าหลายอย่างเมื่อเร็วๆ นี้ เช่น นี้ и นี้, ซึ่งทำให้ VDF ใช้งานได้จริงในทางปฏิบัติมากขึ้น และ Ethereum 2.0 วางแผนที่จะใช้ RANDAO กับ VDF เป็นแหล่งตัวเลขสุ่มในระยะยาว นอกเหนือจากข้อเท็จจริงที่ว่าแนวทางนี้คาดเดาไม่ได้และไม่ลำเอียงแล้ว ยังมีประโยชน์เพิ่มเติมในการสามารถใช้งานได้หากมีผู้เข้าร่วมอย่างน้อยสองคนบนเครือข่าย (สมมติว่าโปรโตคอลฉันทามติที่ใช้นั้นสามารถทำงานได้เมื่อต้องรับมือกับผู้เข้าร่วมจำนวนน้อยเช่นนี้)

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

สำหรับตระกูล VDF ที่กล่าวถึงข้างต้น ประสิทธิภาพของ ASIC เฉพาะอาจสูงกว่าฮาร์ดแวร์ทั่วไปถึง 100+ เท่า ดังนั้น หากระยะการปรับใช้ใช้เวลา 10 วินาที VDF ที่คำนวณบน ASIC ดังกล่าวจะต้องใช้เวลานานกว่า 100 วินาทีจึงจะมีอัตราความปลอดภัยเพิ่มขึ้น 10 เท่า ดังนั้น VDF เดียวกันที่คำนวณบนฮาร์ดแวร์สินค้าโภคภัณฑ์จึงต้องใช้เวลา 100x 100 วินาที = ~3 ชั่วโมง

Ethereum Foundation วางแผนที่จะแก้ไขปัญหานี้ด้วยการสร้าง ASIC ฟรีที่เปิดเผยต่อสาธารณะ เมื่อสิ่งนี้เกิดขึ้น โปรโตคอลอื่นๆ ทั้งหมดก็สามารถใช้ประโยชน์จากเทคโนโลยีนี้ได้ แต่จนกว่าจะถึงตอนนั้น วิธี RANDAO+VDF จะไม่สามารถใช้งานได้กับโปรโตคอลที่ไม่สามารถลงทุนในการพัฒนา ASIC ของตนเองได้

มีการรวบรวมบทความ วิดีโอ และข้อมูลอื่น ๆ เกี่ยวกับ VDF มากมาย เว็บไซต์นี้.

เราใช้รหัสลบ

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

แนวคิดหลักของโปรโตคอลมีดังนี้ เพื่อให้เข้าใจง่าย สมมติว่ามีผู้เข้าร่วม 100 คนพอดี ให้เราสมมติว่าผู้เข้าร่วมทุกคนในเครื่องมีคีย์ส่วนตัวอยู่ และผู้เข้าร่วมทุกคนจะรู้จักคีย์สาธารณะของผู้เข้าร่วมทั้งหมด:

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

2. ผู้เข้าร่วมใช้ฉันทามติบางประเภทเพื่อบรรลุข้อตกลงเกี่ยวกับชุดโค้ดจากผู้เข้าร่วม 67 คน

3. เมื่อบรรลุข้อตกลงร่วมกัน ผู้เข้าร่วมแต่ละคนจะใช้การแบ่งปันที่เข้ารหัสในแต่ละชุดจาก 67 ชุดที่เข้ารหัสด้วยคีย์สาธารณะ ถอดรหัสการแบ่งปันดังกล่าวทั้งหมด และเผยแพร่การแบ่งปันที่ถอดรหัสดังกล่าวทั้งหมด

4. เมื่อผู้เข้าร่วม 67 คนเสร็จสิ้นขั้นตอน (3) ชุดที่ตกลงกันทั้งหมดสามารถถอดรหัสและสร้างใหม่ได้อย่างสมบูรณ์เนื่องจากคุณสมบัติของรหัสการลบ และหมายเลขสุดท้ายสามารถรับเป็น XOR ของแถวเริ่มต้นที่ผู้เข้าร่วมเริ่มต้นด้วยใน (1) .

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

จะเกิดอะไรขึ้นถ้าในขั้นตอน (1) ผู้เข้าร่วมรายใดรายหนึ่งส่งการแชร์ที่เข้ารหัสไปยังผู้เข้าร่วมรายอื่นที่ไม่ใช่รหัสการลบที่ถูกต้องสำหรับสตริงบางรายการ หากไม่มีการเปลี่ยนแปลงเพิ่มเติม ผู้เข้าร่วมที่แตกต่างกันจะไม่สามารถกู้คืนสตริงได้เลย หรือพวกเขาจะกู้คืนสตริงที่แตกต่างกัน ซึ่งจะส่งผลให้ผู้เข้าร่วมแต่ละคนได้รับหมายเลขสุ่มที่แตกต่างกัน เพื่อป้องกันสิ่งนี้ คุณสามารถทำสิ่งต่อไปนี้: ผู้เข้าร่วมแต่ละคน นอกเหนือจากการแชร์ที่เข้ารหัสแล้ว ยังคำนวณอีกด้วย ต้นเมขลา การแบ่งปันดังกล่าวทั้งหมด และส่งผู้เข้าร่วมแต่ละรายทั้งการแบ่งปันที่เข้ารหัสและรากของต้นไม้ Merkle และหลักฐานการรวมส่วนแบ่งในต้นไม้ Merkle ในมติในขั้นตอนที่ (2) ผู้เข้าร่วมไม่เพียงแค่เห็นด้วยกับชุดของชุดเท่านั้น แต่ยังเห็นด้วยกับชุดของรากที่เฉพาะเจาะจงของต้นไม้ดังกล่าว (หากผู้เข้าร่วมบางคนเบี่ยงเบนไปจากเกณฑ์วิธี และส่งรากของต้นไม้ Merkle ที่แตกต่างกันไปยังผู้เข้าร่วมที่แตกต่างกัน และมีการแสดงรากสองอันดังกล่าวในระหว่างการตกลงกัน แถวของเขาไม่รวมอยู่ในชุดผลลัพธ์) จากผลการตกลงร่วมกัน เราจะมีบรรทัดที่เข้ารหัส 67 บรรทัดและรากที่สอดคล้องกันของต้นไม้ Merkle เพื่อให้มีผู้เข้าร่วมอย่างน้อย 67 คน (ไม่จำเป็นต้องเป็นคนเดียวกันที่เสนอบรรทัดที่สอดคล้องกัน) ซึ่งสำหรับแต่ละบรรทัดจาก 67 บรรทัดมี ข้อความที่มีส่วนแบ่งของรหัสการลบ และหลักฐานการเกิดขึ้นของการแบ่งปันในแผนผังที่เกี่ยวข้องนั้นจางหายไป

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

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

2. แถวได้รับการกู้คืนแล้ว แต่รูทที่คำนวณในเครื่องไม่ตรงกับรูทที่บรรลุข้อตกลง

3. แถวไม่ได้รับการกู้คืน

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

ลายเซ็นเกณฑ์

อีกวิธีหนึ่งในการสุ่มคือการใช้สิ่งที่เรียกว่าลายเซ็นเกณฑ์ BLS ตัวสร้างตัวเลขสุ่มตามลายเซ็นเกณฑ์มีการรับประกันเหมือนกันทุกประการกับอัลกอริธึมที่ใช้รหัสการลบตามที่อธิบายไว้ข้างต้น แต่มีจำนวนข้อความกำกับที่ต่ำกว่าอย่างมากที่ส่งผ่านเครือข่ายสำหรับหมายเลขที่สร้างขึ้นแต่ละหมายเลข

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

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

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

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

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

ในข้อสรุป

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

รหัสโปรโตคอลเปิดอยู่ การใช้งานของเราเขียนด้วยภาษา Rust ซึ่งสามารถพบได้ ที่นี่.

คุณสามารถดูการพัฒนาสำหรับ NEAR และทดลองได้ใน IDE ออนไลน์ ที่นี่.

สามารถติดตามข่าวสารภาษารัสเซียทั้งหมดได้ที่ กลุ่มโทรเลข และ กลุ่มบน VKontakteและภาษาอังกฤษอย่างเป็นทางการ พูดเบาและรวดเร็ว.

พบกันเร็ว ๆ นี้!

ที่มา: will.com