Solana (SOL): ธุรกรรมและ Validators ทำงานอย่างไร

สถานะอยู่ในบัญชี

สถานะถาวรทุกชิ้นของ Solana ถูกเก็บไว้ในบัญชีที่ระบุด้วยที่อยู่ 32 ไบต์ บัญชีบันทึก lamports ข้อมูล โปรแกรมเจ้าของ และฟิลด์ที่เกี่ยวข้องกับการทำงาน โปรแกรมเจ้าของคือโปรแกรมที่ได้รับอนุญาตให้เปลี่ยนข้อมูลบัญชีนั้น ไม่จำเป็นต้องเป็นบุคคลที่ควบคุมคีย์กระเป๋าเงิน.

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

กระเป๋าเงิน บัญชีโทเค็น และ PDAs

ที่อยู่กระเป๋าเงินสามารถเป็นเจ้าของ SOL และอนุญาตธุรกรรม แต่ยอดคงเหลือโทเค็น SPL ปกติจะอยู่ในบัญชีโทเค็นที่เชื่อมโยงกับ mint และเจ้าของ ที่อยู่ที่ได้จากโปรแกรม (Program Derived Address) ถูกสร้างขึ้นอย่างกำหนดได้จากโปรแกรม ID และ seeds โปรแกรมสามารถอนุญาตผ่านกฎรันไทม์แม้ว่าจะไม่มีคีย์ส่วนตัวสำหรับที่อยู่นั้น.

ก่อนส่งโทเค็น ให้ยืนยัน mint บัญชีโทเค็นปลายทาง และโปรแกรมที่ถูกเรียก ชื่อย่อหรือป้ายกำกับกระเป๋าเงินที่คุ้นเคยไม่ใช่หลักฐานว่า mint นั้นเป็นมาตรฐาน การปิด การสร้าง หรือการจัดสรรบัญชีใหม่อาจย้าย lamports ดังนั้นควรตรวจสอบสรุปธุรกรรมมากกว่าจำนวนโทเค็นหลัก.

ข้อความ ลายเซ็น และคำสั่ง

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

ความสดใหม่และการยืนยัน

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

ไคลเอนต์ RPC แสดงระดับการยืนยัน processed, confirmed และ finalized อินเทอร์เฟซที่รวดเร็วอาจแสดงผล processed ก่อนที่จะถึงข้อตกลงที่แข็งแกร่งของคลัสเตอร์ การฝากเงิน สะพานเชื่อม และการดำเนินการแอปพลิเคชันที่ขึ้นอยู่กับ ควร รอระดับที่บริการนั้นต้องการ และควรตรวจสอบลายเซ็นผ่าน RPC หรือ explorer ปัจจุบัน.

ส่วนประกอบพื้นฐานและลำดับความสำคัญ

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

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

การตรวจสอบการทำงาน

เก็บ SOL ให้เพียงพอสำหรับค่าธรรมเนียมแม้ว่าสินทรัพย์ที่โอนจะเป็นโทเค็น SPL ก็ตาม ตรวจสอบคำสั่ง compute-budget ใดๆ เนื่องจากสามารถเปลี่ยนขีดจำกัดที่ร้องขอและราคาลำดับความสำคัญได้ นอกจากนี้ ให้แยกแยะค่าธรรมเนียมการทำธุรกรรมออกจากการจัดหาเงินทุนในบัญชี ยอดคงเหลือที่เกี่ยวข้องกับค่าเช่า ผลกระทบราคาสวอป และค่าธรรมเนียมแอปพลิเคชัน สิ่งเหล่านี้เป็นต้นทุนที่แยกจากกันแม้ว่ากระเป๋าเงินหนึ่งใบจะสรุปรวมไว้ด้วยกันก็ตาม.