อัพเดต Agave v2.0 ทั้งหมดที่คุณต้องรู้

ขั้นสูง11/21/2024, 10:40:54 AM
การปล่อย Agave validator client v2.0 หมายถึงขั้นตอนสำคัญที่สำคัญในการเดินทางของ Solana ไปสู่ระบบนิเวศที่มัลติคลายเอนท์แข็งแรงมากขึ้น การอัปเดตนี้นำเสนอการปรับปรุงที่สำคัญหลายอย่างเพื่อเพิ่มประสิทธิภาพของเครือข่าย ความเชื่อถือได้ และความมีประสิทธิภาพ

สรุป Agave 2.0

การเปิดตัว Agave validator client v2.0 เป็นเหตุการณ์สำคัญในการเดินทางของ Solana สู่ระบบนิเวศที่มีความแข็งแกร่งและหลายลูกค้ามากขึ้น อัปเดตนี้มีการปรับปรุงสำคัญหลายอย่างเพื่อเพิ่มประสิทธิภาพของเครือข่าย ความเสถียรและประสิทธิภาพ การเปลี่ยนแปลงหลักในการอัปเดตนี้ รวมถึง:

  • การเปลี่ยนรหัสทั้งหมดและการปรับปรุงเชิงลึกสำหรับโค้ดเบส
  • รางวัลยุคที่แบ่งแยก
  • การตอบแทนค่าธรรมเนียมลำดับความสำคัญเต็มรูปแบบให้กับผู้ตรวจสอบ
  • ตอนนี้เครื่องเชื่อมต่อศูนย์กลางใหม่เปิดใช้งานโดยค่าเริ่มต้น
  • โปรแกรมพิสูจน์ ZK ElGamal
  • Get-Sysvar Syscall
  • GetEpochStake Syscall
  • MoveStake และ MoveLamports
  • การลบวิธี RPC ที่ถูกยกเลิก
  • การเปลี่ยนชื่อตู้

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

ทำให้รุ่น 2.0 เป็นการอัปเดตรุ่นสำคัญ?

ไม่มี 'Solana validator' เดียวอีกต่อไป Agave 2.0 ยอมรับโลก multi-client ใหม่ของ Solana และเป็นจุดพักที่สะอาดจากเก่าที่เก็บของ Solana Labs บน GitHub. ที่เก็บข้อมูลของ Solana Labs จะถูกเก็บถาวร และคำขอดึงข้อมูลใหม่หรือปัญหาจะไม่ได้รับการยอมรับอีกต่อไป ก่อนหน้านี้ ที่เก็บข้อมูลนี้ถูกพิมพ์กิจกรรมจากที่เก็บข้อมูล Agave นักพัฒนาควรย้ายกิจกรรมทั้งหมดไปที่เรือนกังวาล Anza ในระบบ GitHubถ้าพวกเขายังไม่ได้ทำเช่นนั้น ก็กระบวนการโยกย้ายจาก Solana Labs เป็น Agave เริ่มเมื่อวันที่ 1 มีนาคมและมีการติดตามต่อสาธารณะบน GitHub ของพวกเขา

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

กระบวนการที่ได้รับผลกระทบคือ:

solana-validator, solana-ledger-tool, solana-watchtower, solana-install, solana-geyser-plugin-interface, solana-cargo-registry

ตามที่ระบุไว้ในเราคู่มือการเปลี่ยนทางก่อนหน้าในการอัปเดต 2.0 นี้ มีการเปลี่ยนแปลงหลายอย่างที่สำคัญ โดยเฉพาะการลบออกบางส่วนของเอ็นด์พอยท์ที่ล้าสมัยและเบื้องหลัง การอัปเดตสำคัญที่นักพัฒนา Solana ทุกคนควรทราบอยู่แล้ว รายละเอียดเต็มของการเปลี่ยนแปลง RPC รวมอยู่ที่สิ้นสุดของบทความนี้

การเปิดตัวคุณสมบัติ

ในขณะที่เขียน ~ 20.7% ของผู้ตรวจสอบกําลังใช้งานเวอร์ชัน 2.0.14 การเปิดใช้งาน Feature gate บน mainnet จะถูกหยุดชั่วคราวเพื่อให้การปรับใช้ v2.0 สอดคล้องกับการเปิดใช้งานบน testnet และ devnet มากขึ้น เมื่อคลัสเตอร์ mainnet ได้นํา v2.0 มาใช้อย่างกว้างขวางการเปิดใช้งาน feature gate คาดว่าจะกลับมาทํางานต่อตาม ลําดับการเปิดใช้งานตามกําหนดเวลา.

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

รางวัลค่าธรรมเนียมเต็มรูปแบบสำหรับผู้ตรวจสอบ

นี้ถูกคาดว่าจะเป็นอย่างยิ่งและการอัปเดตทางเศรษฐกิจที่ถูกโต้แย้งอย่างมาก กำลังถูกนำไปปฏิบัติตามข้อเสนอ,SIMD-0096, ซึ่งผ่านการลงคะแนนเสียงโดยผู้ตรวจสอบในเดือนพฤษภาคม โดยการลงคะแนนเสร็จสิ้นที่สิ้นสุดของยุค 620 โดยมี 51.17% ของส่วนของแบบสวนและ 77.77% ลงคะแนนเพื่อสนับสนุน การอัพเดตที่เปิดสถานะคุณลักษณะจะเปลี่ยนแปลงพื้นฐานในการจัดการของเครือข่ายค่าธรรมเนียมล่วงหน้า. แทนที่จะเป็นรุ่นปัจจุบันซึ่งแบ่งค่าธรรมเนียมด้วยการเผา 50% และ 50% ตอบแทนให้กับผู้ตรวจสอบความถูกต้องรุ่นใหม่จะจัดสรรค่าธรรมเนียมลําดับความสําคัญ 100% ให้กับผู้ตรวจสอบโดยตรง


ด้านบน: ค่าธรรมเนียมลำดับความสำคัญรายสัปดาห์ของ Solana ในมูลค่าเป็น USD (ที่มา)

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

ค่าการจัดลำดับตามลำดับ = ราคาหน่วยคำนวณ (ไมโครลัมพอร์ต) x ขีดจำกัดหน่วยคำนวณ

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

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

รางวัลของยุคที่ถูกแบ่ง

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

ในการแนวทางใหม่นี้ การคำนวณรางวัลการพนันและการกระจายที่ขอบเขตของยุคจะถูกแบ่งออกเป็นสองระยะทางที่แตกต่างกัน:

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

เพื่อให้การดำเนินงานและการตรวจสอบกระบวนการเป็นไปอย่างราบรื่น บัญชี Sysvar,EpochRewardsจะติดตามและตรวจสอบการกระจายรางวัลตลอดขั้นตอนการจัดจําหน่าย EpochRewards Sysvar จะบันทึกหากขั้นตอนการแจกจ่ายรางวัลอยู่ระหว่างดําเนินการและข้อมูลที่จําเป็นในการแจกจ่ายต่อเมื่อเริ่มต้นจากสแนปช็อต

การคํานวณรางวัล

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

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

การแจกจ่ายรางวัล

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

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

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

ตัวจัดการกลางตอนนี้เปิดใช้งานโดยค่าเริ่มต้น

เปิดตัวครั้งแรกเป็นการเปิดตัวคุณลักษณะในการอัปเดต v1.18 ตัวจัดกําหนดการส่วนกลางซึ่งเดิมเรียกว่า "ตัวจัดกําหนดการ" ไม่ได้เปิดใช้งานตามค่าเริ่มต้นและต้องเปิดใช้งานโดยผู้ปฏิบัติงานโดยใช้แฟล็ก —block-production-method central-scheduler เมื่อเริ่มตัวตรวจสอบความถูกต้อง ตอนนี้จะเปิดตามค่าเริ่มต้น การใช้งานตัวจัดกําหนดการก่อนหน้านี้มีปัญหาหลายประการที่อาจส่งผลเสียต่อประสิทธิภาพการทํางาน ปัญหาคอขวดในการประมวลผลธุรกรรมมักนําไปสู่ความกระวนกระวายใจหรือความไม่สอดคล้องกันในการสั่งซื้อและจัดลําดับความสําคัญของธุรกรรม

การใช้งานที่ใหม่กว่าจะแทนที่รูปแบบก่อนหน้าของเธรดธนาคารอิสระสี่เธรดซึ่งแต่ละเธรดจะจัดการการจัดลําดับความสําคัญและการประมวลผลธุรกรรมของตนเอง ในโครงสร้างที่แก้ไขนี้ตัวกําหนดตารางเวลากลางเป็นผู้รับธุรกรรมแต่เพียงผู้เดียวจากขั้นตอน SigVerify ของ TPU มันสร้างคิวลําดับความสําคัญและปรับใช้กราฟการพึ่งพาหรือที่เรียกว่า prio-graph เพื่อจัดการการประมวลผลและการจัดลําดับความสําคัญของธุรกรรมที่ขัดแย้งกันได้ดีขึ้น การออกแบบตัวจัดกําหนดการใหม่นี้ช่วยเพิ่มความสามารถในการปรับขนาดและความยืดหยุ่นทําให้สามารถเพิ่มจํานวนเธรดได้โดยไม่ต้องกังวลกับความขัดแย้งในการล็อคที่เพิ่มขึ้นก่อนหน้านี้ การเปิดตัวครั้งแรกของตัวกําหนดตารางเวลากลางได้รับการแสดงเพื่อสร้างผลตอบแทนที่ดีขึ้นส่งผลให้รายได้ที่ดีขึ้นสําหรับผู้ให้บริการหลายราย โพสต์ Helius ก่อนหน้าของเราในการอัปเดต Solana v1.18 ที่ครอบคลุมอย่างกว้างขวาง วิธีการทํางานของ Central Scheduler.

โปรแกรมพิสูจน์ ZK ElGamal

โปรแกรม ZK Token Proof ที่เริ่มต้นวางแผนให้เกิดขึ้นในการออกแบบ 1.17 ถูกยกเลิกและจะถูกแทนที่ด้วยโปรแกรมที่หลากหลายมากขึ้น ที่ไม่ขึ้นอยู่กับแอปพลิเคชันโปรแกรมพิสูจน์ ZK ElGamal. โปรแกรม ZK ElGamal Proof ใหม่ยังคงรักษาส่วนของโปรแกรม ZK Token Proof ที่ใช้ในวงกว้างในแอปพลิเคชันต่างๆ เช่น การตรวจสอบความถูกต้องของคีย์สาธารณะหรือช่วงของค่าที่เข้ารหัสภายในข้อความเข้ารหัส ElGamal อย่างไรก็ตามมันละเว้นองค์ประกอบเฉพาะแอปพลิเคชันเช่นการตรวจสอบหลักฐานที่ไม่มีความรู้ที่จําเป็นสําหรับคําแนะนําการถ่ายโอนโทเค็น SPL โปรแกรม ZK ElGamal Proof ใหม่จะรวมอยู่ในรายการโปรแกรมในตัวตามที่อยู่ ZkE1Gama1Proof11111111111111111111111111111.

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับโปรแกรม ZK Token Proof โปรดอ่าน ต้นฉบับเขียนขึ้นในบล็อก Helius.

Get-Sysvar Syscall

Syscalls หรือการเรียกระบบร้องขอบริการจากเคอร์เนลของระบบปฏิบัติการ ในบริบทของ Solana Syscall ช่วยให้โปรแกรมที่ทํางานภายใน Solana Virtual Machine (SVM) สามารถโต้ตอบกับทรัพยากรและบริการภายนอกได้

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

Syscall Get-Sysvar ซึ่งถูกเสนอครั้งแรกในSIMD-127 โดย Anza engineer Joe Caulfieldในการอัปเกรดนี้มีการแนะนำอินเทอร์เฟซ Syscall ที่สมบูรณ์สำหรับการเข้าถึงข้อมูล Sysvar แบบเดียวกัน ซึ่งทำให้สามารถดึงข้อมูล Sysvar ที่ไม่สามารถเข้าถึงได้ก่อนหน้านี้ได้ เช่น SlotHashes และ StakeHistory ด้วยอินเทอร์เฟซใหม่นี้ นักพัฒนาสามารถเข้าถึงชิ้นส่วนของข้อมูล Sysvar ได้โดยเฉพาะ - เช่นการเรียก SlotHashes::get_slot(slot)และStakeHistory::get_entry(epoch)—โดยไม่จำเป็นต้องทำซ้ำโครงสร้างข้อมูลทั้งหมด

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

การนำเสนอ Syscall ใหม่ช่วยในกระบวนการที่ง่ายขึ้นในการปรับเปลี่ยนและเพิ่ม Sysvars โดยมีประสิทธิภาพมากขึ้นและลดความซับซ้อนและความต้องการในการบำรุงรักษาของอินเทอร์เฟซ Syscall อย่างมีนัย. อีกทั้ง การอัพเดทนี้ยัดไปในทางที่จะขยายการเข้าถึงโปรแกรม BPF ไปยังข้อมูล Sysvar โดยทำให้อินเทอร์เฟซ on-chain programs สามารถอ่านข้อมูล Sysvar ได้มากขึ้นโดยไม่มีผลต่อขนาดธุรกรรม

เรียกใช้ Syscall GetEpochStake

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

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

ด้วย GetEpochStake นักพัฒนาซอฟต์แวร์จะให้ที่อยู่บัญชีการลงคะแนนแบบ 32 ไบต์ และ syscall จะส่งคืนจํานวนเต็ม u64 ซึ่งแสดงถึงสัดส่วนการถือหุ้นที่ใช้งานอยู่ทั้งหมดที่มอบหมายให้กับบัญชีการลงคะแนนนั้น หากที่อยู่ที่ให้ไว้ไม่สอดคล้องกับบัญชีการลงคะแนนที่ถูกต้องหรือไม่มีอยู่ Syscall จะส่งคืน 0

MoveStake และ MoveLamports

สองคําแนะนําโปรแกรมสเตคใหม่,MoveStake และ MoveLamports, กำลังถูกนำเสนอขึ้นเพื่อให้ความสะดวกในการโอนค่าระหว่างบัญชีเดิม. คำแนะนำเหล่านี้เสนอครั้งแรกในSIMD-0148ช่วยเหลือนักพัฒนาโดยอนุญาตให้มีการเคลื่อนย้ายเงินระหว่างบัญชีกับหน่วยงานที่ตรงกันโดยไม่มีการควบคุมของผู้มีอํานาจถอนเงิน

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

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

MoveLamports: ย้าย lamports ส่วนเกินจากบัญชีที่ใช้งานอยู่หรือไม่ใช้งานไปยังบัญชีที่ใช้งานอยู่หรือไม่ใช้งานอีกบัญชีหนึ่งโดยที่ "lamports ส่วนเกิน" หมายถึง lamports ที่ไม่ได้มอบอํานาจหรือจําเป็นสําหรับการยกเว้นค่าเช่า MoveLamports ช่วยให้งานทําความสะอาดเช่นการเรียกคืน lamports จากบัญชีที่ควบรวมและการรวมเงินที่ไม่ได้ใช้

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

โบนัส: The Solana-SVM Crate

ด้วยการเปิดตัวของ Agave 2.0 มาชุด solana-svm ใหม่สดการเสนอให้นักพัฒนาสามารถเข้าถึงองค์ประกอบหลักของ SVM โดยตรงผ่าน API ที่เรียบง่ายโดยอิสระจากเฟรมเวิร์กผู้ตรวจสอบทั้งหมด สิ่งนี้เปิดโอกาสให้การประมวลผลธุรกรรมที่มีประสิทธิภาพสูงของ Solana สำหรับแอปพลิเคชันที่เกินกว่าผู้ตรวจสอบ เช่น บริการออฟเชน ไคลเอ็นต์เบา ช่องสถานะ และ rollups

ด้วยการแยก API ออกจากรันไทม์ที่เหลือลังนี้ช่วยลดความจําเป็นในการใช้ส่วนประกอบเช่นอินสแตนซ์ของธนาคารซึ่งช่วยลดค่าใช้จ่ายในการดําเนินงาน ตอนนี้นักพัฒนาสามารถใช้ประโยชน์จากส่วนประกอบที่แข็งแกร่งแบบเดียวกับที่รองรับ mainnet-beta ของ Solana เพื่อสร้างโครงการ SVM ที่กําหนดเองเช่นไคลเอนต์ขนาดเล็กช่องทางของรัฐการยกเลิกและบริการนอกเครือข่าย แกนหลักของ API นี้คือโครงสร้าง TransactionBatchProcessor ซึ่งช่วยให้แอปพลิเคชันสามารถประมวลผลชุดของธุรกรรม Solana ที่ถูกสุขอนามัยด้วยชุดส่วนประกอบ Agave ปลายน้ําเต็มรูปแบบรวมถึง BPF Loader, eBPF และเครื่องเสมือน


ด้านบน: โปรเซสเซอร์แบทช์ธุรกรรม (ที่มาของภาพ: Anza)

อ่านวิเคราะห์ลึกAPI SVM ใหม่ของ Anzaสำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการพัฒนาที่น่าตื่นเต้นนี้

ลบจุดสิ้นสุด RPC

ลบหลายจุดสิ้นสุดการใช้งานและการใช้งานต่อไปของ v1 Agave RPC ที่เลิกใช้แล้ว ทีม Helius Devrel ได้ติดต่อลูกค้าทั้งหมดที่ใช้จุดสิ้นสุดเหล่านี้ ผ่านการวิเคราะห์ภายในเราได้ระบุล่วงหน้าว่ามีกลุ่มเล็ก ๆ ของลูกค้าที่ใช้จุดสิ้นสุดต่อไปนี้อย่างเต็มที่ ซึ่งกำลังจะถูกลบ:

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

อีกครั้ง เราขอแนะนำให้นักพัฒนาทุกคนตรวจสอบการอ้างอิงถึงการเรียกใช้เหล่านี้และอัปเดตโดยเหตุผลที่แนะนำ


ด้านบน: รายการสมบูรณ์ของจุดสิ้นสุดของ Agave RPC เวอร์ชัน 1 ที่ถูกยกเลิกและถูกยกเลิกเพื่อลบ

หมายเหตุ วิธีทางเลือกสำหรับ getAccountInfo ที่แสดงในภาพสามารถพบที่นี่.

การเปลี่ยนแปลงที่ทําลาย SDK ได้แก่:

สำหรับผู้ดำเนินการตรวจสอบความถูกต้อง จะมีการลบอาร์กิวเมนต์ตรวจสอบความถูกต้องที่ถูกยกเลิกหลายรายการขึ้นอยู่กับการเปิดตัวของ Agave v2.0 รายการทั้งหมดเหล่านี้สามารถค้นหาได้ในที่นี่.

สรุป

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

ทรัพยากรเพิ่มเติม/การอ่านเพิ่มเติม

ปฏิเสธ:

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

อัพเดต Agave v2.0 ทั้งหมดที่คุณต้องรู้

ขั้นสูง11/21/2024, 10:40:54 AM
การปล่อย Agave validator client v2.0 หมายถึงขั้นตอนสำคัญที่สำคัญในการเดินทางของ Solana ไปสู่ระบบนิเวศที่มัลติคลายเอนท์แข็งแรงมากขึ้น การอัปเดตนี้นำเสนอการปรับปรุงที่สำคัญหลายอย่างเพื่อเพิ่มประสิทธิภาพของเครือข่าย ความเชื่อถือได้ และความมีประสิทธิภาพ

สรุป Agave 2.0

การเปิดตัว Agave validator client v2.0 เป็นเหตุการณ์สำคัญในการเดินทางของ Solana สู่ระบบนิเวศที่มีความแข็งแกร่งและหลายลูกค้ามากขึ้น อัปเดตนี้มีการปรับปรุงสำคัญหลายอย่างเพื่อเพิ่มประสิทธิภาพของเครือข่าย ความเสถียรและประสิทธิภาพ การเปลี่ยนแปลงหลักในการอัปเดตนี้ รวมถึง:

  • การเปลี่ยนรหัสทั้งหมดและการปรับปรุงเชิงลึกสำหรับโค้ดเบส
  • รางวัลยุคที่แบ่งแยก
  • การตอบแทนค่าธรรมเนียมลำดับความสำคัญเต็มรูปแบบให้กับผู้ตรวจสอบ
  • ตอนนี้เครื่องเชื่อมต่อศูนย์กลางใหม่เปิดใช้งานโดยค่าเริ่มต้น
  • โปรแกรมพิสูจน์ ZK ElGamal
  • Get-Sysvar Syscall
  • GetEpochStake Syscall
  • MoveStake และ MoveLamports
  • การลบวิธี RPC ที่ถูกยกเลิก
  • การเปลี่ยนชื่อตู้

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

ทำให้รุ่น 2.0 เป็นการอัปเดตรุ่นสำคัญ?

ไม่มี 'Solana validator' เดียวอีกต่อไป Agave 2.0 ยอมรับโลก multi-client ใหม่ของ Solana และเป็นจุดพักที่สะอาดจากเก่าที่เก็บของ Solana Labs บน GitHub. ที่เก็บข้อมูลของ Solana Labs จะถูกเก็บถาวร และคำขอดึงข้อมูลใหม่หรือปัญหาจะไม่ได้รับการยอมรับอีกต่อไป ก่อนหน้านี้ ที่เก็บข้อมูลนี้ถูกพิมพ์กิจกรรมจากที่เก็บข้อมูล Agave นักพัฒนาควรย้ายกิจกรรมทั้งหมดไปที่เรือนกังวาล Anza ในระบบ GitHubถ้าพวกเขายังไม่ได้ทำเช่นนั้น ก็กระบวนการโยกย้ายจาก Solana Labs เป็น Agave เริ่มเมื่อวันที่ 1 มีนาคมและมีการติดตามต่อสาธารณะบน GitHub ของพวกเขา

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

กระบวนการที่ได้รับผลกระทบคือ:

solana-validator, solana-ledger-tool, solana-watchtower, solana-install, solana-geyser-plugin-interface, solana-cargo-registry

ตามที่ระบุไว้ในเราคู่มือการเปลี่ยนทางก่อนหน้าในการอัปเดต 2.0 นี้ มีการเปลี่ยนแปลงหลายอย่างที่สำคัญ โดยเฉพาะการลบออกบางส่วนของเอ็นด์พอยท์ที่ล้าสมัยและเบื้องหลัง การอัปเดตสำคัญที่นักพัฒนา Solana ทุกคนควรทราบอยู่แล้ว รายละเอียดเต็มของการเปลี่ยนแปลง RPC รวมอยู่ที่สิ้นสุดของบทความนี้

การเปิดตัวคุณสมบัติ

ในขณะที่เขียน ~ 20.7% ของผู้ตรวจสอบกําลังใช้งานเวอร์ชัน 2.0.14 การเปิดใช้งาน Feature gate บน mainnet จะถูกหยุดชั่วคราวเพื่อให้การปรับใช้ v2.0 สอดคล้องกับการเปิดใช้งานบน testnet และ devnet มากขึ้น เมื่อคลัสเตอร์ mainnet ได้นํา v2.0 มาใช้อย่างกว้างขวางการเปิดใช้งาน feature gate คาดว่าจะกลับมาทํางานต่อตาม ลําดับการเปิดใช้งานตามกําหนดเวลา.

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

รางวัลค่าธรรมเนียมเต็มรูปแบบสำหรับผู้ตรวจสอบ

นี้ถูกคาดว่าจะเป็นอย่างยิ่งและการอัปเดตทางเศรษฐกิจที่ถูกโต้แย้งอย่างมาก กำลังถูกนำไปปฏิบัติตามข้อเสนอ,SIMD-0096, ซึ่งผ่านการลงคะแนนเสียงโดยผู้ตรวจสอบในเดือนพฤษภาคม โดยการลงคะแนนเสร็จสิ้นที่สิ้นสุดของยุค 620 โดยมี 51.17% ของส่วนของแบบสวนและ 77.77% ลงคะแนนเพื่อสนับสนุน การอัพเดตที่เปิดสถานะคุณลักษณะจะเปลี่ยนแปลงพื้นฐานในการจัดการของเครือข่ายค่าธรรมเนียมล่วงหน้า. แทนที่จะเป็นรุ่นปัจจุบันซึ่งแบ่งค่าธรรมเนียมด้วยการเผา 50% และ 50% ตอบแทนให้กับผู้ตรวจสอบความถูกต้องรุ่นใหม่จะจัดสรรค่าธรรมเนียมลําดับความสําคัญ 100% ให้กับผู้ตรวจสอบโดยตรง


ด้านบน: ค่าธรรมเนียมลำดับความสำคัญรายสัปดาห์ของ Solana ในมูลค่าเป็น USD (ที่มา)

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

ค่าการจัดลำดับตามลำดับ = ราคาหน่วยคำนวณ (ไมโครลัมพอร์ต) x ขีดจำกัดหน่วยคำนวณ

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

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

รางวัลของยุคที่ถูกแบ่ง

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

ในการแนวทางใหม่นี้ การคำนวณรางวัลการพนันและการกระจายที่ขอบเขตของยุคจะถูกแบ่งออกเป็นสองระยะทางที่แตกต่างกัน:

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

เพื่อให้การดำเนินงานและการตรวจสอบกระบวนการเป็นไปอย่างราบรื่น บัญชี Sysvar,EpochRewardsจะติดตามและตรวจสอบการกระจายรางวัลตลอดขั้นตอนการจัดจําหน่าย EpochRewards Sysvar จะบันทึกหากขั้นตอนการแจกจ่ายรางวัลอยู่ระหว่างดําเนินการและข้อมูลที่จําเป็นในการแจกจ่ายต่อเมื่อเริ่มต้นจากสแนปช็อต

การคํานวณรางวัล

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

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

การแจกจ่ายรางวัล

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

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

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

ตัวจัดการกลางตอนนี้เปิดใช้งานโดยค่าเริ่มต้น

เปิดตัวครั้งแรกเป็นการเปิดตัวคุณลักษณะในการอัปเดต v1.18 ตัวจัดกําหนดการส่วนกลางซึ่งเดิมเรียกว่า "ตัวจัดกําหนดการ" ไม่ได้เปิดใช้งานตามค่าเริ่มต้นและต้องเปิดใช้งานโดยผู้ปฏิบัติงานโดยใช้แฟล็ก —block-production-method central-scheduler เมื่อเริ่มตัวตรวจสอบความถูกต้อง ตอนนี้จะเปิดตามค่าเริ่มต้น การใช้งานตัวจัดกําหนดการก่อนหน้านี้มีปัญหาหลายประการที่อาจส่งผลเสียต่อประสิทธิภาพการทํางาน ปัญหาคอขวดในการประมวลผลธุรกรรมมักนําไปสู่ความกระวนกระวายใจหรือความไม่สอดคล้องกันในการสั่งซื้อและจัดลําดับความสําคัญของธุรกรรม

การใช้งานที่ใหม่กว่าจะแทนที่รูปแบบก่อนหน้าของเธรดธนาคารอิสระสี่เธรดซึ่งแต่ละเธรดจะจัดการการจัดลําดับความสําคัญและการประมวลผลธุรกรรมของตนเอง ในโครงสร้างที่แก้ไขนี้ตัวกําหนดตารางเวลากลางเป็นผู้รับธุรกรรมแต่เพียงผู้เดียวจากขั้นตอน SigVerify ของ TPU มันสร้างคิวลําดับความสําคัญและปรับใช้กราฟการพึ่งพาหรือที่เรียกว่า prio-graph เพื่อจัดการการประมวลผลและการจัดลําดับความสําคัญของธุรกรรมที่ขัดแย้งกันได้ดีขึ้น การออกแบบตัวจัดกําหนดการใหม่นี้ช่วยเพิ่มความสามารถในการปรับขนาดและความยืดหยุ่นทําให้สามารถเพิ่มจํานวนเธรดได้โดยไม่ต้องกังวลกับความขัดแย้งในการล็อคที่เพิ่มขึ้นก่อนหน้านี้ การเปิดตัวครั้งแรกของตัวกําหนดตารางเวลากลางได้รับการแสดงเพื่อสร้างผลตอบแทนที่ดีขึ้นส่งผลให้รายได้ที่ดีขึ้นสําหรับผู้ให้บริการหลายราย โพสต์ Helius ก่อนหน้าของเราในการอัปเดต Solana v1.18 ที่ครอบคลุมอย่างกว้างขวาง วิธีการทํางานของ Central Scheduler.

โปรแกรมพิสูจน์ ZK ElGamal

โปรแกรม ZK Token Proof ที่เริ่มต้นวางแผนให้เกิดขึ้นในการออกแบบ 1.17 ถูกยกเลิกและจะถูกแทนที่ด้วยโปรแกรมที่หลากหลายมากขึ้น ที่ไม่ขึ้นอยู่กับแอปพลิเคชันโปรแกรมพิสูจน์ ZK ElGamal. โปรแกรม ZK ElGamal Proof ใหม่ยังคงรักษาส่วนของโปรแกรม ZK Token Proof ที่ใช้ในวงกว้างในแอปพลิเคชันต่างๆ เช่น การตรวจสอบความถูกต้องของคีย์สาธารณะหรือช่วงของค่าที่เข้ารหัสภายในข้อความเข้ารหัส ElGamal อย่างไรก็ตามมันละเว้นองค์ประกอบเฉพาะแอปพลิเคชันเช่นการตรวจสอบหลักฐานที่ไม่มีความรู้ที่จําเป็นสําหรับคําแนะนําการถ่ายโอนโทเค็น SPL โปรแกรม ZK ElGamal Proof ใหม่จะรวมอยู่ในรายการโปรแกรมในตัวตามที่อยู่ ZkE1Gama1Proof11111111111111111111111111111.

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับโปรแกรม ZK Token Proof โปรดอ่าน ต้นฉบับเขียนขึ้นในบล็อก Helius.

Get-Sysvar Syscall

Syscalls หรือการเรียกระบบร้องขอบริการจากเคอร์เนลของระบบปฏิบัติการ ในบริบทของ Solana Syscall ช่วยให้โปรแกรมที่ทํางานภายใน Solana Virtual Machine (SVM) สามารถโต้ตอบกับทรัพยากรและบริการภายนอกได้

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

Syscall Get-Sysvar ซึ่งถูกเสนอครั้งแรกในSIMD-127 โดย Anza engineer Joe Caulfieldในการอัปเกรดนี้มีการแนะนำอินเทอร์เฟซ Syscall ที่สมบูรณ์สำหรับการเข้าถึงข้อมูล Sysvar แบบเดียวกัน ซึ่งทำให้สามารถดึงข้อมูล Sysvar ที่ไม่สามารถเข้าถึงได้ก่อนหน้านี้ได้ เช่น SlotHashes และ StakeHistory ด้วยอินเทอร์เฟซใหม่นี้ นักพัฒนาสามารถเข้าถึงชิ้นส่วนของข้อมูล Sysvar ได้โดยเฉพาะ - เช่นการเรียก SlotHashes::get_slot(slot)และStakeHistory::get_entry(epoch)—โดยไม่จำเป็นต้องทำซ้ำโครงสร้างข้อมูลทั้งหมด

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

การนำเสนอ Syscall ใหม่ช่วยในกระบวนการที่ง่ายขึ้นในการปรับเปลี่ยนและเพิ่ม Sysvars โดยมีประสิทธิภาพมากขึ้นและลดความซับซ้อนและความต้องการในการบำรุงรักษาของอินเทอร์เฟซ Syscall อย่างมีนัย. อีกทั้ง การอัพเดทนี้ยัดไปในทางที่จะขยายการเข้าถึงโปรแกรม BPF ไปยังข้อมูล Sysvar โดยทำให้อินเทอร์เฟซ on-chain programs สามารถอ่านข้อมูล Sysvar ได้มากขึ้นโดยไม่มีผลต่อขนาดธุรกรรม

เรียกใช้ Syscall GetEpochStake

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

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

ด้วย GetEpochStake นักพัฒนาซอฟต์แวร์จะให้ที่อยู่บัญชีการลงคะแนนแบบ 32 ไบต์ และ syscall จะส่งคืนจํานวนเต็ม u64 ซึ่งแสดงถึงสัดส่วนการถือหุ้นที่ใช้งานอยู่ทั้งหมดที่มอบหมายให้กับบัญชีการลงคะแนนนั้น หากที่อยู่ที่ให้ไว้ไม่สอดคล้องกับบัญชีการลงคะแนนที่ถูกต้องหรือไม่มีอยู่ Syscall จะส่งคืน 0

MoveStake และ MoveLamports

สองคําแนะนําโปรแกรมสเตคใหม่,MoveStake และ MoveLamports, กำลังถูกนำเสนอขึ้นเพื่อให้ความสะดวกในการโอนค่าระหว่างบัญชีเดิม. คำแนะนำเหล่านี้เสนอครั้งแรกในSIMD-0148ช่วยเหลือนักพัฒนาโดยอนุญาตให้มีการเคลื่อนย้ายเงินระหว่างบัญชีกับหน่วยงานที่ตรงกันโดยไม่มีการควบคุมของผู้มีอํานาจถอนเงิน

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

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

MoveLamports: ย้าย lamports ส่วนเกินจากบัญชีที่ใช้งานอยู่หรือไม่ใช้งานไปยังบัญชีที่ใช้งานอยู่หรือไม่ใช้งานอีกบัญชีหนึ่งโดยที่ "lamports ส่วนเกิน" หมายถึง lamports ที่ไม่ได้มอบอํานาจหรือจําเป็นสําหรับการยกเว้นค่าเช่า MoveLamports ช่วยให้งานทําความสะอาดเช่นการเรียกคืน lamports จากบัญชีที่ควบรวมและการรวมเงินที่ไม่ได้ใช้

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

โบนัส: The Solana-SVM Crate

ด้วยการเปิดตัวของ Agave 2.0 มาชุด solana-svm ใหม่สดการเสนอให้นักพัฒนาสามารถเข้าถึงองค์ประกอบหลักของ SVM โดยตรงผ่าน API ที่เรียบง่ายโดยอิสระจากเฟรมเวิร์กผู้ตรวจสอบทั้งหมด สิ่งนี้เปิดโอกาสให้การประมวลผลธุรกรรมที่มีประสิทธิภาพสูงของ Solana สำหรับแอปพลิเคชันที่เกินกว่าผู้ตรวจสอบ เช่น บริการออฟเชน ไคลเอ็นต์เบา ช่องสถานะ และ rollups

ด้วยการแยก API ออกจากรันไทม์ที่เหลือลังนี้ช่วยลดความจําเป็นในการใช้ส่วนประกอบเช่นอินสแตนซ์ของธนาคารซึ่งช่วยลดค่าใช้จ่ายในการดําเนินงาน ตอนนี้นักพัฒนาสามารถใช้ประโยชน์จากส่วนประกอบที่แข็งแกร่งแบบเดียวกับที่รองรับ mainnet-beta ของ Solana เพื่อสร้างโครงการ SVM ที่กําหนดเองเช่นไคลเอนต์ขนาดเล็กช่องทางของรัฐการยกเลิกและบริการนอกเครือข่าย แกนหลักของ API นี้คือโครงสร้าง TransactionBatchProcessor ซึ่งช่วยให้แอปพลิเคชันสามารถประมวลผลชุดของธุรกรรม Solana ที่ถูกสุขอนามัยด้วยชุดส่วนประกอบ Agave ปลายน้ําเต็มรูปแบบรวมถึง BPF Loader, eBPF และเครื่องเสมือน


ด้านบน: โปรเซสเซอร์แบทช์ธุรกรรม (ที่มาของภาพ: Anza)

อ่านวิเคราะห์ลึกAPI SVM ใหม่ของ Anzaสำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการพัฒนาที่น่าตื่นเต้นนี้

ลบจุดสิ้นสุด RPC

ลบหลายจุดสิ้นสุดการใช้งานและการใช้งานต่อไปของ v1 Agave RPC ที่เลิกใช้แล้ว ทีม Helius Devrel ได้ติดต่อลูกค้าทั้งหมดที่ใช้จุดสิ้นสุดเหล่านี้ ผ่านการวิเคราะห์ภายในเราได้ระบุล่วงหน้าว่ามีกลุ่มเล็ก ๆ ของลูกค้าที่ใช้จุดสิ้นสุดต่อไปนี้อย่างเต็มที่ ซึ่งกำลังจะถูกลบ:

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

อีกครั้ง เราขอแนะนำให้นักพัฒนาทุกคนตรวจสอบการอ้างอิงถึงการเรียกใช้เหล่านี้และอัปเดตโดยเหตุผลที่แนะนำ


ด้านบน: รายการสมบูรณ์ของจุดสิ้นสุดของ Agave RPC เวอร์ชัน 1 ที่ถูกยกเลิกและถูกยกเลิกเพื่อลบ

หมายเหตุ วิธีทางเลือกสำหรับ getAccountInfo ที่แสดงในภาพสามารถพบที่นี่.

การเปลี่ยนแปลงที่ทําลาย SDK ได้แก่:

สำหรับผู้ดำเนินการตรวจสอบความถูกต้อง จะมีการลบอาร์กิวเมนต์ตรวจสอบความถูกต้องที่ถูกยกเลิกหลายรายการขึ้นอยู่กับการเปิดตัวของ Agave v2.0 รายการทั้งหมดเหล่านี้สามารถค้นหาได้ในที่นี่.

สรุป

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

ทรัพยากรเพิ่มเติม/การอ่านเพิ่มเติม

ปฏิเสธ:

  1. บทความนี้ถูกพิมพ์ซ้ำจาก [ helius)]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Lostin]. หากมีการคัดค้านการพิมพ์ซ้ํานี้โปรดติดต่อ Gate Learnทีมของเราจะดูแลมันโดยเร็ว
  2. คำประกาศความรับผิดชอบ: มุมมองและความเห็นที่แสดงในบทความนี้เป็นเพียงเรื่องราวของผู้เขียนเท่านั้นและไม่เป็นที่ปรึกษาการลงทุนใด ๆ
  3. การแปลบทความเป็นภาษาอื่น ๆ ทําโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว เว้นแต่จะกล่าวถึง
Empieza ahora
¡Regístrate y recibe un bono de
$100
!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.