ข่าว 
ข้อมูลเหรียญ 
แนะนำสื่อ 
นักพัฒนาอีเธอเรียม(ETH) กำลังปรับแต่งดีไซน์ EIP-8141 ให้เน้นโครงสร้าง 'เฟรม' (frame) เพื่อขยายฟีเจอร์การทำธุรกรรมโดยไม่ต้องแก้ไขซองธุรกรรม (transaction envelope) เดิม ฟีเจอร์อย่างเวลาหมดอายุของธุรกรรม การรวมลายเซ็น (aggregate signature) และรากเมิร์กเคิลของพูลความเป็นส่วนตัว (privacy pool Merkle root) จะถูกเขียนในรูปแบบการเรียกสัญญา (contract call) แทนที่จะฝังอยู่ในซองธุรกรรมโดยตรง
สื่อคริปโตเกาหลีใต้ อูบล็อกเชน(U Blockchain) รายงานเมื่อวันที่ 7 เวลา 06:37 น. (เวลาเกาหลีใต้) ว่า เดอริก เชียง(Derek Chiang) นักพัฒนาอีเธอเรียม อธิบายทิศทางล่าสุดของ EIP-8141 ไว้เช่นนี้ เอกสารทางการของ EIP-8141 เรียกข้อเสนอนี้ว่า 'เฟรมทรานแซคชัน' (frame transaction) ซึ่งเป็นประเภทธุรกรรมใหม่ที่แบ่งขั้นตอนตรวจสอบ การประมวลผล และการจ่ายค่าแก๊สออกเป็นหลายเฟรม
หัวใจของแนวทางนี้คือการลดการเปลี่ยนแปลงซองธุรกรรมให้น้อยที่สุด เพราะซองธุรกรรมเป็นรูปแบบพื้นฐานที่กระเป๋าเงินดิจิทัล บล็อกเอ็กซ์พลอเรอร์ ชุดพัฒนาซอฟต์แวร์ (SDK) และโครงสร้างพื้นฐานเลเยอร์ 2 (L2) ใช้อ่านร่วมกัน หากส่วนนี้เปลี่ยนไป ไม่ใช่แค่เมนเน็ตอีเธอเรียมที่ต้องปรับตัว แต่เครื่องมือและบริการโดยรอบทั้งหมดต้องปรับตามไปด้วย
EIP-8141 จึงพยายามผลักฟีเจอร์ใหม่เข้าไปอยู่ในเฟรมแทน เพื่อลดภาระการประสานงานทั่วทั้งระบบนิเวศ ด้วยรอบการอัปเกรดของอีเธอเรียมที่ค่อนข้างยาวนาน แนวคิดเบื้องหลังคือหากต้องแก้ซองธุรกรรมทุกครั้งที่จะเพิ่มฟีเจอร์ใหม่ ต้นทุนการปรับตัวของทั้งระบบนิเวศจะยิ่งสูงขึ้นเรื่อยๆ
เอกสาร EIP-8141 ระบุว่าเฟรมทรานแซคชันจะแยกขั้นตอนการตรวจสอบ การอนุมัติจ่ายค่าแก๊ส และการประมวลผลคำสั่งของผู้ใช้ออกเป็นเฟรมที่เรียงลำดับกัน ตามเอกสาร ธุรกรรมประเภทนี้บรรจุเฟรมได้สูงสุด 64 เฟรม และแต่ละเฟรมมีเพดานแก๊สสำหรับการประมวลผลและแก๊สสำหรับสถานะ (state gas) แยกจากกัน
สำหรับผู้ใช้ทั่วไป ดีไซน์นี้เชื่อมโยงกับฟีเจอร์บัญชีนามธรรม (account abstraction) อย่างการทำธุรกรรมแบบกลุ่ม (batch transaction) การจ่ายค่าแก๊สด้วยสินทรัพย์อื่นแทน ETH และการเปลี่ยนคีย์บัญชี ที่ผ่านมาผู้ใช้ส่วนใหญ่ผูกติดอยู่กับการดูแลคีย์ส่วนตัวและต้องถือ ETH ไว้จ่ายค่าธรรมเนียม หากบัญชีนามธรรมถูกนำมาใช้จริง ฟีเจอร์อย่างบัญชีอัจฉริยะ (smart account) ธุรกรรมที่มีผู้อื่นออกค่าแก๊สให้ (sponsored transaction) และการประมวลผลหลายคำสั่งในครั้งเดียว จะรองรับได้กว้างขึ้น
อย่างไรก็ตาม ความยืดหยุ่นของแนวทางเฟรมก็มาพร้อมข้อถกเถียงเรื่องความซับซ้อน เชียงเขียนในบทความของ Ether Labs เมื่อวันที่ 25 สิงหาคมว่า ชุมชนนักพัฒนาหลักของอีเธอเรียม 'เลือกยอมรับความยืดหยุ่นของเฟรม มากกว่าข้อเสนอบัญชีนามธรรมแบบตายตัว' บทความเดียวกันระบุว่า EIP-8130 ที่เสนอโดยเบส(Base) ได้จุดประเด็นถกเถียงนี้ขึ้นมาอีกครั้ง
EIP-8130 เป็นข้อเสนอที่ทำให้บัญชีนามธรรมเกิดขึ้นได้ผ่านการจัดโครงสร้างบัญชีบนเชน (on-chain) ร่วมกับธุรกรรมประเภทใหม่ เอกสารทางการระบุว่าธุรกรรมจะต้องระบุตัวตรวจสอบสิทธิ์ (authenticator) ที่จะใช้ ทำให้โหนดสามารถกรองธุรกรรมได้โดยไม่ต้องรันโค้ดกระเป๋าเงินที่ไม่รู้จักตามอำเภอใจ ซึ่งเป็นแนวทางที่ต่างจาก EIP-8141 ที่พยายามทำให้การตรวจสอบและการประมวลผลเป็นนามธรรมในวงกว้างขึ้นผ่านเฟรม
อูบล็อกเชนรายงานว่า เชียงมองว่าการทำให้เป็นนามธรรมมากเกินไปอาจลดความสามารถในการอ่านทำความเข้าใจธุรกรรมลงได้ ด้วยเหตุนี้ นักพัฒนาจึงกำลังพิจารณาแนวทางผสาน EIP-8141 เข้ากับ EIP-8130 ซึ่งเป็นมาตรฐานบัญชี เพื่อเพิ่มข้อจำกัดเชิงโครงสร้างให้กับเฟรม เป็นทิศทางที่ต้องการรักษาความยืดหยุ่นไว้ พร้อมกับเสริมกรอบที่กระเป๋าเงินและโครงสร้างพื้นฐานตีความได้
ทั้งนี้ โทเคนโพสต์เคยรายงานความคืบหน้าการพัฒนา EIP-8141 และการถกเถียงเรื่องเทสต์เน็ตของเฟรมมาอย่างต่อเนื่อง ซึ่งขณะนั้นก็มีการประเมินว่าการมีประเด็นด้านการพัฒนาที่ยังเปิดอยู่ ไม่ได้แปลว่าจะถูกนำไปใช้บนเมนเน็ตจริงหรือรวมอยู่ในการอัปเกรดใดอัปเกรดหนึ่งแน่นอน
การถกเถียงล่าสุดสะท้อนว่างานวิจัยด้านรูปแบบธุรกรรมของอีเธอเรียมกำลังก้าวข้ามการเพิ่มปริมาณการประมวลผล (throughput) ไปสู่ขั้นออกแบบโครงสร้างธุรกรรมใหม่ทั้งระบบ ประเด็นที่ต้องถกกันต่อคือจะแยกเงื่อนไขที่ต้องตรวจสอบออกจากการกระทำที่ต้องประมวลผลจริงได้มากแค่ไหน และผลลัพธ์นั้นกระเป๋าเงินกับ L2 จะตีความอย่างไร
สำหรับผู้ใช้ในประเทศไทย จุดที่เกี่ยวข้องโดยตรงไม่ใช่ราคาในระยะสั้น แต่เป็นเรื่องการใช้งานจริง หากโครงสร้างเฟรมถูกนำมาใช้ การจัดการค่าธรรมเนียมของกระเป๋าเงิน การประมวลผลหลายคำสั่งพร้อมกัน และวิธีกู้คืนบัญชีหรือเปลี่ยนคีย์อาจเปลี่ยนไป ในทางกลับกัน หากภาระการพัฒนาเพิ่มขึ้น ความเร็วในการปรับตัวของผู้ให้บริการกระเป๋าเงินและโครงสร้างพื้นฐานจะกลายเป็นตัวแปรสำคัญ
EIP-8141 ยังอยู่ในขั้นร่างตามเอกสารทางการ ส่วนจะถูกนำไปใช้บนเมนเน็ตจริงหรือไม่และเมื่อใด ต้องรอการถกเถียงของนักพัฒนาหลักและการทดสอบไคลเอนต์ (client) ต่อไป
ความคิดเห็น 0