ชื่อและการต่ออายุ

การต่ออายุ TLD และความปลอดภัย SLD

ชุมชน SLD ต้องอาศัย TLD แม่ของ Handshake ที่ยังใช้งานได้ สิ่งที่ทำอัตโนมัติได้ขึ้นอยู่กับวิธีควบคุมเหรียญเจ้าของปัจจุบันของ TLD

คำตอบสั้น ๆ

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

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

ข้อจำกัดสำคัญ: เหลือเพียงการต่ออายุที่ทำได้

สคริปต์ยอมรับ RENEW แต่ไม่ยอมรับ UPDATE ระเบียนทรัพยากร Handshake เดิมจะถูกส่งต่อและตรึงถาวร ไม่มีใคร ไม่ว่าเจ้าของเดิม ผู้ถือ SLD, Bob, Impervious หรือชุมชน จะเปลี่ยนระเบียน NS, DS, TXT, glue หรือระเบียน Handshake อื่นของ TLD ในภายหลังได้

รูปแบบควบคุมสี่แบบที่ต่างกัน

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

การต่ออายุปกติใน Bob ทำงานอย่างไร

ชื่อ Handshake ต้องได้รับธุรกรรม RENEW บนเชนภายในช่วงต่ออายุ (ประมาณสองปีบน mainnet) การยืนยันความต่อเนื่องนี้เป็นส่วนหนึ่งของโปรโตคอล Handshake ตามบันทึกการออกแบบและ คำถามที่พบบ่อยของ Handshake สาธารณะ ไม่ใช่กฎของ Bob Wallet การต่ออายุคงการจดทะเบียนให้ใช้งานและรักษาข้อมูลทรัพยากรปัจจุบัน ไม่ใช่การซื้อซ้ำ

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

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

covenant สำหรับยืนยันความต่อเนื่องคือ RENEW ไม่ใช่ UPDATE ส่วน UPDATE เปลี่ยนข้อมูลทรัพยากร Handshake ของชื่อ

ใครก็ต่ออายุได้ แต่ไม่มีใครอัปเดตระเบียนได้

กฎสคริปต์ของ Handshake อนุญาตให้โอนชื่อไปยังสคริปต์ที่ยอมรับเฉพาะการกระทำ RENEW ที่อยู่ mainnet ตามเอกสารคือ:

hs1qu3nrzrjkd783ftpk7l4hvpa96aazx5dddw66hgs2zuukckcchrqsw3f8kc

สคริปต์คือ OP_TYPE OP_8 OP_EQUAL โดย covenant ประเภท 8 คือ RENEW หลังทำขั้นตอนสุดท้ายของการโอนไปที่อยู่นี้ กระเป๋าเงินที่ไม่เกี่ยวข้องสามารถจัดหาและลงนามอินพุตค่าธรรมเนียม ขณะที่สคริปต์สาธารณะทำให้เงื่อนไขอินพุตชื่อที่ล็อกไว้ครบ เหรียญเจ้าของที่ต่ออายุจะยังล็อกกับสคริปต์เดิมและคงข้อมูลทรัพยากรเดิม

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

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

การตัดสินใจด้านความปลอดภัยที่ย้อนกลับไม่ได้

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

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

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

การ staking กับ Impervious ไม่ใช่หลักฐานว่าล็อกแล้ว

คู่มือ Impervious ที่มีอยู่เริ่มจากตั้งค่าระเบียน NS และ TXT แล้วลงรายการหรือ stake TLD จากนั้นอธิบายขั้นตอนโอนให้ชุมชนแยกต่างหากโดยใช้ที่อยู่ต่ออายุอย่างเดียว ดังนั้น TLD อาจตั้งค่าหรือลงรายการกับ Impervious โดยยังไม่ทำล็อกที่ย้อนกลับไม่ได้ให้เสร็จ

กระเป๋าเงิน ตัวสำรวจ หรือบริการติดตามต้องตรวจเหรียญเจ้าของ Handshake ปัจจุบัน ไม่ควรติดป้าย TLD ว่า “ใครก็ต่ออายุได้” เพียงเพราะชื่อปรากฏในรายการของระบบทะเบียน

วิธีตรวจสอบล็อก

  1. อ่านสถานะชื่อปัจจุบันจากโหนด Handshake ที่ซิงค์แล้ว
  2. รับแฮชธุรกรรมเจ้าของปัจจุบันและดัชนีเอาต์พุตของชื่อ
  3. ดึงเหรียญเจ้าของที่ยังไม่ถูกใช้จ่ายนั้น
  4. เปรียบเทียบ witness program กับแฮชสคริปต์ต่ออายุอย่างเดียวมาตรฐานของเครือข่ายที่ใช้งาน
  5. บันทึกความสูงการต่ออายุ บล็อกที่เหลือ outpoint เจ้าของ และบล็อกที่สังเกต
  6. ตรวจซ้ำทันทีก่อนสร้างธุรกรรมต่ออายุใด ๆ

ควรแสดงความสัมพันธ์กับระบบทะเบียนและสถานะการควบคุมของเจ้าของแยกกัน เช่น “ลงรายการใน Impervious” และ “ตรวจสอบล็อกต่ออายุอย่างเดียวแล้ว”

อยู่ระหว่างพิจารณา

LearnHNS Renewal Guardian

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

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

ไม่ควรมีบริการใดเก็บวลีกู้คืน คีย์ส่วนตัว หรือรหัสผ่านกระเป๋าเงิน Bob เพื่อให้บริการติดตามการต่ออายุ

แล้ว Snitch ล่ะ?

การพูดคุยใน HandyCon อธิบาย “Snitch” ในอดีตของ Kiba ว่าเป็นระบบวางหลักประกันทางเศรษฐกิจหรือตัดหลักประกัน: เจ้าของ TLD ยังคงควบคุม วางเงินไว้ในสมาร์ตคอนแทรกต์ และเสี่ยงเสียเงินฝากหากเปลี่ยนระเบียนทะเบียนที่ให้สัญญาไว้ วิธีนี้อาจยับยั้งการจงใจทำให้ผู้ถือ SLD เสียหาย แต่ต่างจากให้บุคคลที่สามมีสิทธิ์ต่ออายุ TLD ที่กระเป๋าเงินควบคุม

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

เอกสารอ้างอิงทางเทคนิค