บทนำ

“เราทราบถึงขนาดเล็ก เร็ว และถูกกว่าใครๆ ในโลก และตอนนี้เรากำลังปรับใช้แนวคิดเหล่านั้นในบล็อกเชน” — เกร็ก ฟิทซ์เจอรัลด์ ร่วมก่อตั้ง Solana

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

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

Solana กำลังพัฒนาอย่างรวดเร็ว พร้อมกับการพัฒนาที่เร็ว ๆ เช่น SVM rollups และการบีบอัด ZKเป็นการแก้ปัญหาการขยายมาตรฐานที่สำคัญ ขณะที่โครงการเหล่านี้อาจจะเป็นผู้ร่วมกำหนดมุมมองของเราต่อ Solana ในอนาคต แต่ในขณะนี้พวกเขากำลังอยู่ในช่วงเริ่มต้นของการพัฒนาหรือการนำมาใช้งานและจะไม่ถูกนำเสนอในรายงานนี้

วงจรชีวิตของธุรกรรม

มุมมองหลักของเราในการเข้าใจ Solana ตลอดรายงานนี้จะเป็นชีวิตของธุรกรรมปกติ โดยการสร้างโมเดลพื้นฐานเพื่อเข้าใจธุรกรรม Solana เราสามารถเรียกเส้นทางการดำเนินงานตามนี้:

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

ส่วนถัดไปของรายงานนี้จะขยายโมเดลนี้และศึกษากระบวนการนี้อย่างละเอียดมากขึ้นเริ่มต้นด้วยผู้เข้าร่วมสำคัญ—ผู้ใช้งาน

จำ

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

หกขั้นตอน

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

บทก่อนหน้าจะถูกจัดเรียงตามหกขั้นตอนเหล่านี้ บทสุดท้าย - สะท้าน, ข้อมูลเก่า, เศรษฐศาสตร์ และ Jito - จะเชื่อมโยงปลายเชือกใด ๆ สำคัญที่จะระบุว่าบางบทอาจครอบคลุมหลายขั้นตอน และบางขั้นตอนจะปรากฏในหลายบท

ความทับซ้อนนี้ไม่สามารถหลีกเลี่ยงได้เนื่องจากกรอบงาน 6 ขั้นตอนมีข้อจำกัด ในความเป็นจริง Solana เป็นระบบกระจายที่ซับซ้อนมีองค์ประกอบหลายอย่างที่สื่อสารกัน

ผู้ใช้

“Solana มีศักยภาพที่จะเป็น Apple ของโลกคริปโต” — Raj Gokal, ผู้ก่อตั้ง Solana

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

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

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

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

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

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

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

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

การทำธุรกรรม Solana

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

• หัวเรื่อง: หัวเรื่องประกอบด้วยการอ้างอิงไปยังรายการที่มีที่อยู่บัญชี ที่ระบุถึงบัญชีที่ต้องลงนามในการทำธุรกรรม
• ที่อยู่บัญชี: รายการนี้รวมถึงบัญชีทั้งหมดที่จะถูกอ่านหรือเขียนข้อมูลในระหว่างการทำธุรกรรม การสร้างรายการแบบนี้สำหรับทุกๆ การทำธุรกรรมเป็นข้อกำหนดที่เป็นเอกลักษณ์ของ Solana และอาจทำให้นักพัฒนามีความท้าทาย อย่างไรก็ตาม การทราบล่วงหน้าว่าธุรกรรมจะมีปฏิสัมพันธ์กับชิ้นส่วนของสถานะใด ๆ ช่วยให้การปรับปรุงที่เป็นไปไม่ได้บนบล็อกเชนอื่น ๆ ได้
• Blockhash ล่าสุด: ใช้เพื่อป้องกันการทำธุรกรรมที่ซ้ำซ้อนและเก่า. Blockhash ล่าสุดจะหมดอายุหลังจาก 150 บล็อก (ประมาณ 1 นาที). โดยค่าเริ่มต้น RPCs พยายามส่งต่อธุรกรรมทุก 2 วินาทีจนกว่าธุรกรรมจะเสร็จสิ้นหรือ blockhash ล่าสุดหมดอายุ ณ จุดนั้น จะทิ้งธุรกรรมลง
• คำแนะนำ: เหล่านี้เป็นส่วนสำคัญของธุรกรรม แต่ละคำแนะนำแทนการดำเนินการเฉพาะ (เช่น โอน, พิมพ์, เผา, สร้างบัญชี, ปิดบัญชี) แต่ละคำแนะนำระบุโปรแกรมที่จะดำเนินการ บัญชีที่จำเป็น และข้อมูลที่ต้องการสำหรับการดำเนินการของคำแนะนำ

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

จำ

หน่วยเล็กที่สุดของ SOL ที่เรียกว่า “ลัมพอร์ต”, เทียบเท่ากับหนึ่งในพันของ SOL, คล้ายกับซาโตชิในบิตคอยน์ ลัมพอร์ตมีชื่อมาจากLeslie Lamport, นักวิทยาศาสตร์คอมพิวเตอร์และนักคณิตศาสตร์ผู้ทำวิจัยที่สร้างรากฐานทฤษฎีของระบบกระจายสมัยใหม่มากมาย

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

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

ค่าธรรมเนียมทั้งหมด = ค่าธรรมเนียมการจัดลำดับ + ค่าธรรมเนียมฐาน

ค่าสิทธิพิเศษ = ราคาหน่วยคำนวณ (ไมโครแลมพอร์ต) x ขีดจำกัดหน่วยคำนวณ

ปัจจุบัน 50% ของค่าธรรมเนียมที่เกี่ยวข้องกับธุรกรรมทั้งหมดถูกเผาไหม้อย่างถาวรโดยละ ซอลนานี้จากการหมุนเวียนโดยที่ 50% ที่เหลือจะไปที่ผู้ผลิตบล็อก มีการเปลี่ยนแปลงใหม่ (SIMD 96) ที่จะถูกนำเสนอเร็ว ๆ นี้ที่จะทำให้ 100% ของค่าธรรมเนียมการจัดลำดับไปที่ผู้ผลิตบล็อก ค่าธรรมเนียมฐานยังคงเดิม

‍

ส่งธุรกรรม

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

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

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

ผู้提供บริการ RPC (Remote Procedure Call) เป็นตัวกลางระหว่างแอปพลิเคชันและผู้ตรวจสอบที่สร้างบล็อก พวกเขาเป็นบริการสำคัญที่ทำให้แอปพลิเคชันสามารถส่งหรือจำลองการทำธุรกรรมที่ได้รับลายเซ็นและดึงข้อมูลบนเชนได้อย่างมีประสิทธิภาพ แอปพลิเคชันที่ต้องการที่จะโต้ตอบกับเครือข่ายจะใช้ผ่านจุดสิ้นสุด JSON-RPC หรือ WebSocketเอกสาร).

จำ

คำว่า "ธุรกรรมล้มเหลว" บน Solana มีการบอกเกินและทำให้สับสนมาก ธุรกรรมเหล่านี้เกิดค่าธรรมเนียมและดำเนินการได้สำเร็จตามที่ผู้ลงนามตั้งใจไว้ แต่พวกเขา "ล้มเหลว" เนื่องจากตรรกะของธุรกรรมต้องการให้ทำเช่นนั้น +80% ของธุรกรรม "ล้มเหลว" มาจากรหัสข้อผิดพลาด 0x1771 รหัสสำหรับเกินจำนวนการสลิปเปจข้อมูล). ความสำคัญอยู่ที่ 95% ของธุรกรรมเหล่านี้ถูกส่งโดยเพียง 0.1% ของที่อยู่ Solana ที่ทำงานอยู่โดยส่วนใหญ่เป็นบอทอัตโนมัติพยายามใช้ประโยชน์จากโอกาสอารบิเทรจที่อาจเกิดขึ้นภายในเวลาที่มีการคำนวณ

กระแสเอฟต์

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

RPCs (Remote Procedure Calls) หมายถึงโหนด RPC โหนดเหล่านี้สามารถถือเป็นประตูเข้าสู่การจับคู่และอ่านข้อมูลจากเครือข่ายได้พวกเขาเรียกใช้ซอฟต์แวร์เดียวกันกับผู้ตรวจสอบแบบเต็ม แต่มีการตั้งค่าที่แตกต่างกันทำให้พวกเขาสามารถจำลองธุรกรรมอย่างแม่นยำและรักษาระบบมองเห็นของสถานะปัจจุบันได้อย่างทันที ณ ตอนนี้มีโหนด RPC กว่า 4,000 โหนดบนเครือข่าย Solana

โหนด RPC ไม่เก็บ stake ในเครือข่าย เนื่องจากไม่มี stake จึงไม่สามารถลงคะแนนหรือสร้างบล็อก ระบบเซ็ตอัปนี้แตกต่างจากบล็อกเชนอื่น ๆ โดยทั่วไปที่โหนด validator และ RPC มักเป็นคนเดียวกัน โดยที่โหนด RPC ไม่ได้รับรางวัลจากการ stake ดังนั้นเศรษฐศาสตร์ในการทำงานของโหนด RPC แตกต่างจากของ validator โดยมีหลายๆ โหนดทำงานเป็นบริการที่เสียค่าใช้จ่ายสำหรับนักพัฒนาที่ทำงานกับ Solana applications

Solana stands out because it was designed from the outset to operate without a mempool. Unlike traditional blockchains that use gossip protocols to randomly and broadly propagate transactions across the network, Solana forwards all transactions to a predetermined lead validator, known as the leader, for each slot.

Callout

Solana ดำเนินการด้วย 4 คลัสเตอร์: Localnet, Testnet, Devnet, และ Mainnet-Beta เมื่อผู้คนอ้างถึง Solana หรือเครือข่าย Solana เขาเกือบทุกครั้งจะอ้างถึง Mainnet-Beta Mainnet-Beta เป็นเพียงคลัสเตอร์เดียวที่ทำให้โทเคนถือมูลค่าจริง ในขณะที่คลัสเตอร์อื่นใช้เฉพาะเพื่อการทดสอบเท่านั้น

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

คุณภาพบริการที่สำคัญของการถือหุ้น - SWQoS

ปี 2024 ต้นๆ Solana ได้เสนอกลไกใหม่ที่มุ่งเน้นไปที่การป้องกันสแปมและเพิ่มความทนทานต่อ Sybil ที่รู้จักในชื่อ “Stake-Weighted Quality of Service” (SWQoS) ระบบนี้ช่วยให้ผู้นำสามารถกำหนดลำดับความสำคัญของข้อความธุรกรรมที่ถูกหมายเหตุผ่าน validator ที่มีการเดิมพันได้ ที่นี่ validator ที่มีการเดิมพันสูงกว่าได้รับสิทธิ์ในการส่งข้อความธุรกรรมไปยังผู้นำได้มากขึ้นอย่างสัมพันธ์ แนวทางนี้ช่วยลดอันดับการโจมตี Sybil จากโหนดที่ไม่ได้มีการเดิมพันทั่วเครือข่ายได้อย่างมีประสิทธิภาพ

ภายใต้โมเดลนี้ผู้ตรวจสอบยังสามารถมีส่วนร่วมในข้อตกลงในการเช่าความสามารถในการถ่วงน้ําหนักเดิมพันไปยังโหนด RPC ในทางกลับกันโหนด RPC ได้รับแบนด์วิดท์ที่เพิ่มขึ้นทําให้สามารถบรรลุอัตราการรวมธุรกรรมที่มากขึ้นในบล็อก โดยเฉพาะอย่างยิ่ง 80% ของความจุของผู้นํา (2,000 การเชื่อมต่อ) สงวนไว้สําหรับ SWQoS ส่วนที่เหลืออีก 20% (500 การเชื่อมต่อ) จะถูกจัดสรรสําหรับข้อความธุรกรรมจากโหนดที่ไม่ได้เดิมพัน กลยุทธ์การจัดสรรนี้สะท้อนให้เห็นถึงเลนลําดับความสําคัญบนทางหลวงซึ่งผู้ขับขี่จ่ายค่าผ่านทางเพื่อหลีกเลี่ยงการจราจร

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

บันทึก QUIC

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

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

กล่องเรียก

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

การสร้างบล็อก

"เราพิจารณา SVM (Solana Virtual Machine) ว่าเป็นที่ดีที่สุดในเทคโนโลยีเครื่องจำลองปัจจุบัน" - Andre Cronje, มูลนิธิ Fantom

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

แต่ละช่องรอบละ 400 มิลลิวินาที และแต่ละผู้นำได้รับมอบหมายช่องที่เป็นติดกัน 4 ช่อง (1.6 วินาที) ก่อนการหมุนเวียนไปยังผู้นำถัดไป สำหรับบล็อกที่จะได้รับการยอมรับ ธุรกรรมทั้งหมดภายในนั้นต้องถูกต้องและสามารถทำซ้ำได้โดยโหนดอื่น

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

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

Banking Stage

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

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

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

เมื่อธุรกรรมถูกจัดกลุ่มเป็นรายการแล้ว ธุรกรรมเหล่านั้นก็พร้อมที่จะดําเนินการโดย Solana Virtual Machine (SVM) บัญชีที่จําเป็นสําหรับการทําธุรกรรมจะถูกล็อค มีการตรวจสอบเพื่อยืนยันว่าธุรกรรมเป็นรายการล่าสุด แต่ยังไม่ได้รับการประมวลผล บัญชีจะถูกโหลดและตรรกะการทําธุรกรรมจะถูกดําเนินการอัปเดตสถานะบัญชี แฮชของรายการจะถูกส่งไปยังบริการพิสูจน์ประวัติที่จะบันทึก (เพิ่มเติมเกี่ยวกับเรื่องนี้ในส่วนถัดไป) หากกระบวนการบันทึกสําเร็จการเปลี่ยนแปลงทั้งหมดจะถูกส่งไปยังธนาคารและล็อคในแต่ละบัญชีที่วางไว้ในขั้นตอนแรกจะถูกยกขึ้น การดําเนินการจะทําโดย SVM ซึ่งเป็นเครื่องเสมือนที่สร้างขึ้นโดยใช้ส้อม Solana ของ rBPF, ห้องสมุดสำหรับการทำงานกับการคอมไพล์ JIT และเครื่องจำลองสำหรับโปรแกรม eBPF โปรดทราบว่า Solana ไม่กำหนดว่าผู้ตรวจสอบจะเลือกจัดเรียงธุรกรรมอย่างไรภายในบล็อก ความยืดหยุ่นนี้เป็นจุดสำคัญที่เราจะกลับมาพูดถึงในส่วนเศรษฐศาสตร์ + ส่วน Jito ในรายงานนี้

จำ

คำว่า SVM อาจมีความกำกวมเนื่องจากมันอาจอ้างถึง "Solana Virtual Machine" หรือ "Sealevel Virtual Machine" ทั้งสองคำนี้กล่าวถึงแนวคิดเดียวกันโดย Sealevel เป็นชื่อของสภาพแวดล้อมการทำงานของ Solana คำว่า SVM ยังคงถูกใช้โดยไม่แน่นอนอย่างต่อเนื่อง แม้ว่ามีความพยายามเพื่อให้แม่นยำกำหนดขอบเขตของมัน.

ผู้ใช้งาน

Solana เป็นเครือข่ายที่ประกอบด้วยโหนดที่ดําเนินการอย่างอิสระหลายพันโหนดที่ทํางานร่วมกันเพื่อรักษาบัญชีแยกประเภทแบบรวมศูนย์เดียว แต่ละโหนดประกอบด้วยเครื่องประสิทธิภาพสูงที่ใช้ซอฟต์แวร์โอเพ่นซอร์สเดียวกันที่เรียกว่า "ไคลเอนต์"

Solana ได้เริ่มต้นด้วยซอฟต์แวร์ไคลเอ็นต์ของผู้ตรวจสอบเดียว — ต้นฉบับคือ Solana Labs client ซึ่งตอนนี้เป็นที่รู้จักกันAgave client— เขียนด้วย Rust การขยายความหลากหลายของลูกค้าเป็นความสำคัญตั้งแต่แรกและจะเป็นจริงจริงกับการเปิดตัวFiredancer clientFiredancer เป็นการเขียนโค้ดขึ้นมาใหม่ทั้งหมดของไคลเอนต์เดิมในภาษาโปรแกรม C ที่สร้างขึ้นโดยทีมผู้เชี่ยวชาญจากบริษัทซื้อขายหลายโทรศัพท์ Jump ซึ่งสัญญาว่าจะเป็นไคลเอนต์ที่มีประสิทธิภาพที่สุดบนบล็อกเชนใดก็ตาม

พิสูจน์ของประวัติศาสตร์

“ฉันดื่มกาแฟ 2 แก้วและเบียร์ 1 ขวด และตื่นอยู่จนถึง 4:00 นาฬิกาเช้า ฉันมีช่วงเวลาอุปราคาว่า ประมาณเกี่ยวกับการทำงานใช้ SHA-256 ฟังก์ชันแฮชที่ต้านทาน preimage-resistant เดียวกัน… ฉันรู้ว่าฉันมีลูกธนูของเวลา” — Anatoly Yakovenko ผู้ร่วมก่อตั้ง Solana

Proof of History (PoH) เป็นเครื่องปรุงลับของ Solana ทำหน้าที่เหมือนนาฬิกาพิเศษในแต่ละผู้ตรวจสอบที่สะท้อนการประสานข้อมูลในเครือข่าย PoH จัดตั้งแหล่งข้อมูลที่เชื่อถือได้สำหรับลำดับของเหตุการณ์และการผ่านเวลา สำคัญที่สุดคือการให้ความเชื่อถือตามกำหนดของผู้นำ ถึงแม้จะมีชื่อที่คล้ายกัน Proof of History ไม่ใช่อัลกอริทึมในการตัดสินในรูปแบบ Proof of Work

ความล่าช้าในการสื่อสารระหว่างโหนดมักเพิ่มขึ้นเมื่อเครือข่ายขยายตัว และการประสานงานกลายเป็นซับซ้อนขึ้นอย่างมาก Solana ช่วยลดปัญหานี้ด้วยการแทนที่การสื่อสารระหว่างโหนดกับ PoH local computation นี้หมายความว่า validators สามารถยอมรับบล็อกด้วยการโหวตแค่รอบเดียวเท่านั้น การใช้เครื่องหมายเวลาที่เชื่อถือได้ในข้อความทำให้ validators ไม่สามารถกระโดดข้ามกันและเริ่มบล็อกของตนล่วงหน้าได้

พื้นที่ PoH คือคุณสมบัติที่ไม่ซ้ำกันของอัลกอริทึมการแฮช โดยเฉพาะSHA256:

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

ภายในแต่ละไคลเอ็นต์ของผู้ตรวจสอบ มี "Proof of History service" ที่มีการทำงานอย่างต่อเนื่องด้วยอัลกอริทึม SHA256 ที่สร้างเชนของ hashes โดย input ของ hash แต่ละต่อมาจาก output ของ hash ก่อนหน้า ลำดับของเชนนี้ทำหน้าที่เหมือนกับฟังก์ชันการล่าช้าที่สามารถตรวจสอบได้ เนื่องจากงานการทำ hash จะต้องทำตามลำดับและผลลัพธ์ของ hash ในอนาคตไม่สามารถทราบล่วงหน้าได้ หาก PoH service สร้างเชนของหนึ่งพัน hashes เราทราบว่าเวลาผ่านไปเพื่อที่จะคำนวณแต่ละ hash ตามลำดับ — สิ่งนี้สามารถคิดเป็นเหมือน "micro proof of work" อย่างไรก็ตาม ผู้ตรวจสอบอื่น ๆ สามารถตรวจสอบความถูกต้องของหนึ่งพัน hashes นั้นพร้อมกันในอัตราที่เร็วกว่ามากโดยข้อมูล input และ output ของ hash แต่ละออกไปยังเครือข่าย ดังนั้น PoH เป็นเรื่องยากที่จะสร้าง แต่ง่ายที่จะตรวจสอบ

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

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

ในบล็อกเดียวมี 800,000 แฮช กระแส PoH ยังรวมถึง "ติ๊ก" ซึ่งเป็นรายการว่างที่บ่งชี้ถึงความมีชีวิตของผู้นำและการผ่านเวลาที่เป็นค่าประมาณของเศษส่วนเล็กน้อยของวินาที ติ๊กเกิดขึ้นทุก 6.25 มิลลิวินาที ทำให้เกิดติ๊ก 64 ต่อบล็อก และเวลาบล็อกทั้งหมด 400 มิลลิวินาที

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

จำ

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

โมเดลบัญชี

การแยกโค้ดและสถานะใน SVM คือ การตัดสินใจในการออกแบบที่ดีที่สุด ทรงพระเจริญแก่นักพัฒนาระบบฝังตัวที่ซ้อมคอนเซ็ปต์นี้ให้กับสมองของฉันอย่างเคร่งครัด - Anatoly Yakovenko, ผู้ก่อตั้ง Solana

ภายใน Solana ของ validator สถานะโลกถูกบำรุงรักษาอยู่ในฐานข้อมูลบัญชีที่รู้จักกันว่า AccountsDB ฐานข้อมูลนี้รับผิดชอบในการจัดเก็บบัญชีทั้งหมดทั้งในหน่วยความจำและในดิสก์ โครงสร้างข้อมูลหลักในดัชนีบัญชีคือ hashmap ซึ่งทำให้ AccountsDB เป็นขนาดใหญ่โดยพื้นฐานร้านค้าค่าคีย์-ค่าค่า. ที่นี่ คีย์คือที่อยู่บัญชี และค่าคือข้อมูลบัญชี

เมื่อเวลาผ่านไป จำนวนบัญชี Solana ได้เพิ่มขึ้นเป็นร้อยล้านบัญชี จำนวนมากนี้เกิดขึ้นบางส่วนเพราะ นักพัฒนา Solana ชอบพูดว่า "ทุกอย่างบน Solana เป็นบัญชี!"

บัญชี Solana

บัญชีคือตัวเอนทิตี้ที่บรรจุข้อมูลอย่างต่อเนื่อง คล้ายกับไฟล์บนคอมพิวเตอร์ พวกเขามาในรูปแบบต่าง ๆ

• บัญชีผู้ใช้: บัญชีเหล่านี้มีคีย์ส่วนตัวและมักถูกสร้างขึ้นโดยซอฟต์แวร์กระเป๋าเงินสำหรับผู้ใช้
• บัญชีข้อมูล: บัญชีเหล่านี้เก็บข้อมูลสถานะ เช่น จำนวนของโทเค็นที่ผู้ใช้ถือ
• บัญชีโปรแกรม: นี่คือบัญชีขนาดใหญ่ที่มี bytecode ที่สามารถใช้ปฏิบัติได้ คล้ายกับไฟล์ .exe บน Windows หรือไฟล์ .app บน Mac
• บัญชีโปรแกรม Native: นั้นเป็นบัญชีโปรแกรมที่ถูกติดตั้งล่วงหน้าเฉพาะเพื่อปฏิบัติหน้าที่หลักต่าง ๆ ของเครือข่ายตัวอย่างรวมถึงโปรแกรมโหวตและโหลดเบี้ยประมาณของ BPF

บัญชีทั้งหมดมีฟิลด์ต่อไปนี้:

โปรแกรม

บัญชีโปรแกรม Solana มีเพียงตัวต่าง ๆ ที่เป็นตัวประมวลผลเท่านั้น ซึ่งหมายความว่าเมื่อโปรแกรมถูกเรียกใช้ จะเปลี่ยนแปลงสถานะของบัญชีอื่น ๆ แต่ตัวโปรแกรมเองไม่เปลี่ยนแปลงเลย การแยกโค้ดและสถานะนี้ทำให้ Solana แตกต่างจากบล็อกเชนอื่น ๆ และรองรับการปรับปรุงหลาย ๆ อย่างของมัน นักพัฒนาเขียนโปรแกรมเหล่านี้โดยส่วนใหญ่ใน Rust ซึ่งเป็นภาษาโปรแกรมแบบทั่วไปทราบเนื่องจากการให้ความสำคัญกับความปลอดภัยและประสิทธิภาพอย่างแข็งแกร่ง นอกจากนี้ยังมี SDK หลายรายการใน TypeScript และ Python ที่มีให้บริการเพื่อให้ง่ายต่อการสร้างหน้าจอแอปพลิเคชันและเพิ่มความสามารถในการโต้ตอบกับเครือข่ายโดยอัตโนมัติ

ฟังก์ชันที่สามารถใช้งานได้มากมายถูก提供โดยโปรแกรมภายในไว้ในตัว ตัวอย่างเช่น Solana ไม่需要นักพัฒนาที่จะนำโค้ดไปใช้สร้างโทเค็น แทนที่นั้น คำสั่งจะถูกส่งไปยังโปรแกรมภายในที่ถูกนำไปใช้ไว้ก่อนแล้ว ซึ่งจะตั้งค่าบัญชีเพื่อเก็บข้อมูลเกี่ยวกับโทเค็น โดยที่เป็นไปอย่างมีประสิทธิภาพในการสร้างโทเค็นใหม่

เช่า

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

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

การเป็นเจ้าของ

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

การเก็บข้อมูลของสถานะ

โปรแกรม Solana ซึ่งเป็นไฟล์ที่สามารถอ่านได้อย่างเดียว จะต้องเก็บสถานะโดยใช้ "Program Derived Addresses" (PDAs) PDAs เป็นประเภทพิเศษของบัญชีที่เชื่อมโยงกับโปรแกรมและเป็นเจ้าของโดยเฉพาะ ในขณะที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ที่ปกติของ Solana ที่ใช้สำหรับที่อยู่ผู้ใช้ที่ถูกสร้างจากคีย์สาธารณะของคู่คีย์ Ed25519 PDAs ไม่มีคีย์ส่วนตัว แต่คีย์สาธารณะของพวกเขาถูกสร้างจากการผสมผสานของพารามิเตอร์- คำหลักหรือที่อยู่บัญชีอื่น ๆ ร่วมกับ ID โปรแกรม (ที่อยู่) ของโปรแกรมเจ้าของ

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

ข้างต้น: บัญชีโทเค็น Solana เป็นตัวอย่างเฉพาะของที่อยู่ที่มีขึ้นจากโปรแกรม (PDAs) พวกเขาถูกใช้เพื่อเก็บโทเค็นและอาศัยอยู่นอกเส้นโค้ง โปรแกรมบัญชีโทเค็นที่เกี่ยวข้อง (ATA) รับรองว่าแต่ละกระเป๋าเงินสามารถมีบัญชีโทเค็นที่เกี่ยวข้องได้เพียงหนึ่งบัญชีสำหรับแต่ละประเภทโทเค็น โดยให้วิธีมาตรฐานในการจัดการบัญชีโทเค็น

เรือเดินทะเล

“ส่วนที่น่าสนใจที่สุดของ Solana ไม่ใช่การขนส่งข้อมูลแบบขนาน, SVM, หรือทวีตของ Toly มันคือสิ่งหนึ่งที่คุณอาจยังไม่เคยได้ยิน: Turbine.” — Mert Mumtaz, Helius

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

Turbine เป็นกระบวนการที่ผู้นำส่งเสริมบล็อกของตนไปยังเครือข่ายทั้งหมด ได้แรงบันดาลใจจากBitTorrent, ออกแบบให้เร็วและมีประสิทธิภาพโดยลดการใช้ทรัพยากรสื่อสารและลดปริมาณข้อมูลที่ผู้นำต้องส่ง

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

ชิ้นเล็กชิ้นน้อยจะถูกจัดกลุ่มเป็นชุดที่เรียกว่าแบทช์การแก้ไขข้อผิดพลาดไปข้างหน้า (FEC) โดยค่าเริ่มต้นแบทช์เหล่านี้ประกอบด้วย 64 ชิ้นย่อย (32 ชิ้นย่อยข้อมูล + 32 ชิ้นกู้คืน) การกู้คืนข้อมูลเกิดขึ้นต่อแบทช์ FEC ซึ่งหมายความว่าแพ็กเก็ตมากถึงครึ่งหนึ่งในแบทช์อาจสูญหายหรือเสียหายและข้อมูลทั้งหมดยังสามารถกู้คืนได้ แต่ละชุดฉีก 64 ชุดจะถูกแมร์เคิลโดยที่รากถูกลงนามโดยผู้นําและล่ามโซ่ไว้กับชุดก่อนหน้า กระบวนการนี้ช่วยให้มั่นใจได้ว่าสามารถได้รับชิ้นส่วนอย่างปลอดภัยจากโหนดใด ๆ ในเครือข่ายที่ครอบครองเนื่องจากห่วงโซ่ของราก Merkle ให้เส้นทางที่ตรวจสอบได้ของความถูกต้องและความซื่อสัตย์

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

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

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

ความเห็น

“บางคนที่ฉลาดบอกฉันว่ามีชุมชนนักพัฒนาที่ฉลาดอย่างจริงจังใน Solana ... ฉันหวังว่าชุมชนจะได้รับโอกาสโต้ตอบที่เป็นธรรมในการเจริญเติบโต” - Vitalik Buterin, Ethereum ร่วมก่อตั้ง

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

กระบวนการนี้ได้รับการจัดการโดยหน่วยตรวจสอบธุรกรรม (TVU) ซึ่งเปรียบเสมือนกับหน่วยประมวลผลธุรกรรมของผู้นำ (TPU) ซึ่งทำหน้าที่เป็นตรรกะหลักที่รับผิดชอบการประมวลผลเศรษฐและการตรวจสอบบล็อก คล้ายกับ TPU การไหลของ TVU ถูกแบ่งออกเป็นหลายขั้นตอน เริ่มต้นด้วยขั้นตอนการเรียกรับ Shred ที่ shreds ได้รับผ่าน Turbine ในขั้นตอนต่อมา Shred Verify Leader Signature Stage shreds ผ่านการตรวจสอบสมบูรณ์หลายครั้ง โดยสำคัญที่สุดคือการตรวจสอบลายเซ็นของผู้นำซึ่งทำให้มั่นใจว่า shreds ที่ได้รับเริ่มจากผู้นำ

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

เวทีการเล่นซ้ำคือเหมืองข้อมูลเทียบเท่าใน TPU; มันเป็นเวทีที่สำคัญที่สุดและสามารถอธิบายโดยตรงมากขึ้นว่าเป็นเวทีการตรวจสอบบล็อก Replay เป็นกระบวนการวนซ้ำในเส้นทางเดียวที่จัดการดำเนินการหลายอย่างเช่นการลงคะแน, รีเซ็ตนาฬิกา PoH และสลับธนาคาร

ข้างต้น: สเตจการทำซ้ำรับผิดชอบในการสลับวาลิเดเตอร์เข้าสู่โหมดผู้นำและเริ่มการผลิตบล็อก ภาพต้นฉบับ: Justin Starry, Anza

การเห็นพ้อง

เพื่อให้มีความเห็นกัน Solana ใช้ Tower BFT (TBFT) ซึ่งเป็นการประมวลผลที่ปรับแต่งของ Practical ที่มีชื่อเสียงความผิดพลาดของบีซันตีนอัลกอริทึมความทนทาน (PBFT) ซึ่งใช้โดยบ่อยๆ ในบล็อกเชนส่วนมากเพื่อตกลงกันเกี่ยวกับสถานะของโซลานา อย่างที่บล็อกเชนทั้งหมด โซลานามีการสมมติถึงการมีโหนดที่เป็นโปรแกรมที่มีความผิดปกติในเครือข่ายดังนั้นระบบจึงต้องทนทานต่อการล้มเหลวของโหนดและระดับบางของการโจมตี

Tower BFT ทำตัวแตกต่างจากโซ่อื่น ๆ โดยการใช้ประโยชน์จากนาฬิกาที่ประสานกันที่ Proof of History ในขณะที่ PBFT เดิมต้องการการสื่อสารหลายรอบเพื่อตกลงกันเกี่ยวกับลำดับการทำธุรกรรมโหนด Solana ใช้ลำดับเหตุการณ์ที่กำหนดไว้ล่ะลายลงเหลือเฉพาะการสื่อสารที่ลดลงได้อย่างมีนัยยะ

การลงคะแนนเสียง

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

Forks

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

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

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

อัตราการข้ามของ Solana - เปอร์เซ็นต์ของช่องที่บล็อกไม่ได้ถูกสร้าง - เปลี่ยนไปตั้งแต่ 2% ถึง 10% โดยการแฝงเป็นเหตุผลหลักของช่องที่ข้ามเหล่านี้ สาเหตุที่เป็นไปได้อื่น ๆ สำหรับช่องที่ข้ามรวมถึงเริ่มของยุคใหม่ แลนเดอร์เป็นออฟไลน์ หรือการผลิตบล็อกที่ไม่ถูกต้อง

จำ

สถานะของธุรกรรมบน Solana จะแตกต่างขึ้นอยู่กับขั้นตอนปัจจุบันในกระบวนการตรวจสอบความเห็น

• Processed: ธุรกรรมได้รับการรวมอยู่ในบล็อก

• ยืนยัน: บล็อกการทำธุรกรรมได้รับการลงคะแนโดยส่วนใหญ่สองในสาม

• Finalized: มีการสร้างบล็อกมากกว่า 31 บล็อกบนบล็อกของธุรกรรมแล้ว

จนถึงปัจจุบัน ยังไม่เคยมีเหตุการณ์ใด ๆ ในประวัติศาสตร์ของ Solana ที่บล็อกที่ได้รับการยืนยัน (อย่างเต็มใจ) ไม่ได้กลายเป็นสิ้นสุด

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

การสนทนา + การเก็บถาวร

“บล็อกเชนต้องการการผสมผสานอย่างชาญฉลาดระหว่างการใช้ระบบสาธารณะเข้ารหัส ระบบกระจาย ระบบปฏิบัติการ และภาษาโปรแกรมมิ่ง พลังเฉพาะของ Solana คือการพร้อมที่จะหนีหนีไปห่างจากปัญหาที่น่าสนใจที่สุดในแต่ละวิชา” — Greg Fitzgerald ผู้ก่อตั้ง Solana

สบาย

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

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

การพูดคุยทำงานเป็นระบบที่เรียกได้ว่าเป็นระบบที่เรียกเก็บเอาไว้เอง อิสระจากส่วนประกอบของ validator อื่น ๆ มากที่สุด Validators และ RPCs แบ่งปันวัตถุข้อมูลที่ลงนามไว้ทุก ๆ 0.1 วินาทีผ่าน UDP ผ่านการพูดคุย โดยการให้ความพร้อมข้อมูลทั่วไปในเครือข่าย ข้อความทั้งหมดที่พูดคุยต้องมีขนาดเล็กกว่าหรือเท่ากับหน่วยส่งออกสูงสุด (MTU) ของ 1280 ไบต์ ที่อ้างอิงว่าเป็น "packet struct" ในโค้ดเบส

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

มีสี่ประเภทของข้อความนินทา:

• Push: ข้อความที่พบบ่อยที่สุด การแบ่งปันข้อมูลกับกลุ่มย่อยของ "เพียร์การแสดงผล"
• การดึงและการตอบสนองดึง: ตรวจสอบเป็นระยะๆ เพื่อความสูญหายของข้อความ โดยการตอบสนองดึงจะส่งกลับข้อมูลที่โหนดไม่มี
• Prune: ช่วยให้โหนดสามารถลดจำนวนการเชื่อมต่อที่พวกเขารักษาไว้ได้โดยเลือก
• Ping & Pong: การตรวจสอบสุขภาพสำหรับโหนด​—หากส่ง ping มา จะต้องมี pong กลับมา ซึ่งหมายถึงโหนดเพื่อนยังคงใช้งานอยู่

ข้อมูลข่าวลือถูกเก็บไว้ในร้านค้าข้อมูลที่ทำการคัดลอกในคลัสเตอร์ (CrdsTable) โครงสร้างข้อมูลนี้สามารถขยายขนาดได้มากและต้องตัดแต่งเป็นระยะๆ

เก็บถาวร

Solana ยอดเยี่ยมจากบล็อกเชนอื่นๆ โดยไม่ต้องการประวัติทั้งหมดเพื่อกำหนดสถานะปัจจุบันของบัญชี โมเดลบัญชีของ Solana รับรองว่าสถานะในช่องใดก็ทราบได้ ทำให้ผู้ตรวจสอบสามารถจัดเก็บสถานะปัจจุบันของแต่ละบัญชีโดยไม่ต้องประมวลผลบล็อกที่ผ่านมาทั้งหมด RPCs และผู้ตรวจสอบตามการออกแบบไม่เก็บข้อมูลของบัญชีทั้งหมด แต่พวกเขามักจะเก็บข้อมูลธุรกรรมจำนวน 1 หรือ 2 ยุค (2-4 วัน) ค่าข้อมูลการทำธุรกรรมที่เพียงพอที่จะตรวจสอบปลายสายของโซ่

ปัจจุบันคลังข้อมูลได้รับการจัดการโดย "โหนดคลังสินค้า" ซึ่งดําเนินการโดยผู้ให้บริการ RPC มืออาชีพ Solana Foundation และผู้เข้าร่วมระบบนิเวศอื่น ๆ ที่สนใจเพื่อให้แน่ใจว่ามีประวัติการทําธุรกรรม โหนดคลังสินค้ามักจะรักษาอย่างใดอย่างหนึ่งหรือทั้งสองอย่างต่อไปนี้:

1. บันทึกข้อมูล: อัปโหลดข้อมูลประวัติและสแนปช็อตของบัญชีดีบีที่เหมาะสำหรับการเล่นซ้ำใหม่

2. Google Bigtable Instance: เก็บข้อมูลบล็อกตั้งแต่บล็อก genesis เป็นต้นไป จัดรูปแบบเพื่อให้บริการคำขอ RPC

เศรษฐกิจ + Jito

“คนรู้สึกว่า Solana เป็นเครือข่ายที่พร้อมใช้งานได้เพียงเครือข่ายเดียวที่รองรับแอปพลิเคชันสำหรับผู้บริโภคที่ใช้งานได้” — เท็ด ลิฟวิงสัน, ผู้ก่อตั้ง Code

Solana ใช้การเพิ่มเงินเพื่อกระจายรางวัลการจับคู่โดยการสร้างโทเค็น SOL ใหม่ในแต่ละยุค กระบวนการนี้ทำให้ส่วนแบ่งของเครือข่ายของผู้ไม่ได้ทำการจับคู่ลดลงต่อเทียบกับผู้ที่ทำการจับคู่ ทำให้มีการโอนทรัพย์สินจากผู้ไม่ได้ทำการจับคู่ไปยังผู้ที่ทำการจับคู่ การเพิ่มเงินเริ่มต้นในต้นปี 2021 ที่อัตราเริ่มต้น 8% ซึ่งลดลงทุกปี 15% จนกว่าจะคงที่ที่ อัตรา 1.5% ในระยะยาว

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

‍

รางวัลการลงคะแนนเสียง

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

ผู้ตรวจสอบที่ดำเนินงานได้ดีที่สุดสามารถลงคะแนนให้กับประมาณ 90% ของช่องช่องสล็อต โปรดทราบว่าเปอร์เซ็นต์ของช่องช่องที่ไม่มีบล็อก (อัตราช่องที่ข้าม) อยู่ในช่วง 2% ถึงมากกว่า 10% และช่องเหล่านี้ไม่สามารถลงคะแนนได้ ผู้ตรวจสอบเฉลี่ยลงคะแนนสำเร็จในประมาณ 80% ของช่องช่องสล็อต ได้รับ 345,600 เครดิตในยุคของ 432,000 ช่องช่องสล็อต

โอกาสทั้งหมดจะถูกแบ่งออกตามเครดิตที่ได้รับสำหรับยุคแรก สัดส่วนของเครดิตทั้งหมดของผู้ตรวจสอบ (เครดิตของพวกเขาหารด้วยผลรวมของเครดิตของผู้ตรวจสอบทั้งหมด) กำหนดส่วนแบ่งของพวกเขาไว้สำหรับรางวัลตามสัดส่วน นอกจากนี้ยังมีการคำนวณน้ำหนักต่อการเสี่ยง

ดังนั้น ผู้ตรวจสอบที่มี 1% ของการ์ดรวมควรได้รับรางวัลประมาณ 1% ของการตั้งเกิดรวมหากมีจำนวนการ์ดเฉลี่ย หากมีจำนวนการ์ดเกินหรือน้อยกว่าเฉลี่ย รางวัลของพวกเขาจะเปลี่ยนแปลงตามนั้น

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

รางวัลบล็อก

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

Liquid staking

การจ่ายเงินมัดจำเป็นการเลือกที่นิยมเมื่อเปรียบเทียบกับการถือครองเดิม ผู้เข้าร่วมจะได้รับโทเค็นที่เรียกว่า Liquid Staking Token (LST) หรือ Liquid Staking Derivative (LSD) เป็นตอบแทนสำหรับการจ่ายเงินมัดจำ SOL ของพวกเขา โดยทั่วไปจะอยู่ในสระเงินทุนที่มอบหมายโทเคนของพวกเขาให้กับผู้ตรวจสอบหลายคน โทเคน LST ที่ได้รับใหม่แทนส่วนแบ่งของผู้ใช้ใน SOL ที่ถือครอง โทเคนเหล่านี้สามารถถูกซื้อขายใช้ในแอปพลิเคชันหรือโอนให้ผู้อื่นได้โดยยังคงได้รับรางวัลจากการจ่ายเงินมัดจำ ประโยชน์สำคัญของระบบนี้คือมันเพิ่มประสิทธิภาพทางเงินทุนอย่างมีนัยสำคัญ

ราคาของ LST = (SOL ที่เดินทางรวมในสระ * ราคาของ SOL) / จำนวน LST ที่เริ่มได้

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

Jito

ณ เวลาเขียน, มากกว่า 80% ( แหล่งที่มา) ของเงินเดิมพันบน Solana ใช้ซอฟต์แวร์ตรวจสอบลูกค้า Jito โดยลูกค้านี้เป็นการแบ่งแยกของลูกค้า Agave เดิม ที่นำเสนอการประมูลพื้นที่บล็อกนอกโปรโตคอลซึ่งจะมอบสิ่งประกันเศรษฐกิจเพิ่มเติมให้กับตัวตรวจสอบผ่านทิป สิ่งประกันเพิ่มเติมนี้เป็นปัจจัยสำคัญในการนำลูกค้า Jito ไปใช้งานอย่างแพร่หลายในหมู่ตรวจสอบ

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

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

การประมูล Blockspace เกิดขึ้นนอกเครือข่ายผ่าน Jito Block Engine ทําให้ผู้ค้นหาและแอปพลิเคชันสามารถส่งกลุ่มธุรกรรมที่ดําเนินการด้วยอะตอมที่เรียกว่าการรวมกลุ่ม กลุ่มเหล่านี้มักจะมีธุรกรรมที่ไวต่อเวลาเช่น arbitrages หรือการชําระบัญชี Jito เรียกเก็บค่าธรรมเนียม 5% สําหรับเคล็ดลับทั้งหมดโดยมีทิปขั้นต่ํา 10,000 lamports เคล็ดลับดําเนินการนอกโปรโตคอลทั้งหมดแยกจากลําดับความสําคัญในโปรโตคอลและค่าธรรมเนียมพื้นฐาน ก่อนหน้านี้ Jito ดําเนินการบริการ mem-pool นอกโปรโตคอลแบบบัญญัติซึ่งตอนนี้เลิกใช้แล้ว

ข้อความปฏิเสธความรับผิดชอบ：

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