ขอขอบคุณเป็นพิเศษสำหรับ Jon Charbonneau และ Conor McMenamin สำหรับการทบทวนบทความนี้

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

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

กฎการยืนยัน: ความสอดคล้องเทียบกับความพร้อมใช้งาน

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

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

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

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

อีฟไม่รู้ว่าบ๊อบออฟไลน์อยู่หรืออยู่บนพาร์ติชันเครือข่ายอื่น

บล็อกเชน เช่น Bitcoin ซึ่งใช้ฉันทามติเหมือน Nakamoto นั้นสนับสนุนความมีชีวิตชีวา ซึ่งหมายความว่าในระหว่างการแยกเครือข่าย ทั้งสองฝ่ายจะยังคงสร้างบล็อกต่อไป และในที่สุดจะรวมตัวกันใหม่หาก พาร์ติชันได้รับการแก้ไข ในขณะที่บล็อกอื่น ๆ เช่น Cosmos chain ที่ใช้คล้าย PBFT ฉันทามติ หยุดภายใต้พาร์ติชันเครือข่ายเพื่อรักษาความสอดคล้องกัน

กฎการยืนยันบน Ethereum

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

ภายใต้เงื่อนไขเครือข่ายที่ดี Ethereum ยังมุ่งหวังที่จะรับประกันความสม่ำเสมอจนถึงขั้นสุดท้าย โดยใช้โปรโตคอล Casper FFG Finality เป็นกฎการยืนยันที่แข็งแกร่งที่สุดเท่าที่จะเป็นไปได้ โดยโหนดมีกฎแบบฮาร์ดโค้ดที่จะไม่มีวันจัดระเบียบบล็อกที่สรุปผลใหม่

บัญชีแยกประเภทที่สรุปผลแล้ว (สีเขียว) จะเป็นคำนำหน้าของบัญชีแยกประเภทที่ใช้งานจริง (สีน้ำเงิน) เสมอ

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

ผู้ใช้สามารถเลือกได้ว่าจะใช้ Casper FFG เป็นกฎการยืนยันที่ปลอดภัยที่สุดหรือใช้งานได้จริงมากขึ้นโดยอาศัย LMD GHOST กฎการยืนยันสำหรับ LMD GHOST เช่นเดียวกับ กฎการยืนยัน k ใน Bitcoin อาจมีความซับซ้อนมากกว่าการดูว่าธุรกรรมนั้นรวมอยู่ในบัญชีแยกประเภทหรือไม่ ตามที่ระบุไว้ใน กฎการยืนยัน Safe Block

กฎการยืนยันเกี่ยวกับการยกเลิก

ตามหลักการแล้ว Rollups สามารถใช้กฎการยืนยันเดียวกันที่มีอยู่บน Ethereum หากคุณส่งธุรกรรมเป็นชุดสะสม และต่อมาเห็นธุรกรรมเดียวกันที่โพสต์บน L1 ในบล็อกที่สรุปผลแล้ว คุณอาจต้องการพิจารณาธุรกรรม L2 ถือเป็นที่สิ้นสุดด้วย ปรากฎว่าเรื่องราวซับซ้อนกว่านี้มาก

การยกเลิกข้อมูลธุรกรรม

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

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

ค่าสะสมส่วนต่างของรัฐ

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

เทคนิคการรวมหลักฐานเสนอวิธีแก้ปัญหาสำหรับการแลกเปลี่ยนระหว่างเวลายืนยันและการตัดจำหน่ายต้นทุน: แม้ว่าการรวบรวมจะมีกิจกรรมน้อยที่สุด แต่ก็ยังสามารถได้รับประโยชน์จากการตัดจำหน่ายโดยรวมธุรกรรมจากการรวบรวมที่ใช้งานมากขึ้นไว้ในหลักฐานเดียวกัน ตัวอย่างของแนวทางนี้คือ SHARP โดย Starkware ซึ่งปัจจุบันได้รวบรวมหลักฐานจาก Starknet, Paradex และ StarkEx rollups เช่น dYdX และแม้แต่ Validiums

ที่ซึ่งสิ่งต่างๆ มีความซับซ้อน

ข้อกำหนดการสืบทอดมาของ Rollup

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

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

บน OP Stack chains เวลาบล็อกคือ 2 วินาที ส่งผลให้มี 6 บล็อกภายในแต่ละบล็อก Ethereum การจัดกลุ่ม 6 บล็อกระหว่างบล็อก Ethereum นี้เรียกว่า "ยุค" ข้อความ L1-to-L2 ที่ส่งผ่าน L1 จะรวมอยู่ในส่วนแรกของบล็อกแรกของยุคที่สอดคล้องกันสำหรับบล็อก L1 ที่กำหนด แม้ว่าธุรกรรมเหล่านี้สามารถพิจารณายืนยันได้โดยไม่ต้องรอให้หน้าต่างลำดับผ่านไป เนื่องจากทราบลำดับภายใน L2 ledger เมื่อได้รับมา สิ่งสำคัญคือต้องทราบว่าโหนดจะไม่เริ่มบล็อกการคำนวณที่มีข้อความเหล่านี้ หากไม่มีชุดก่อนหน้าหายไป เนื่องจากสถานะไม่สามารถคำนวณได้หากไม่มีลำดับที่สมบูรณ์ ดังนั้น รากของสถานะจะไม่ถูกเผยแพร่บน L1 เช่นกัน

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

ฟังก์ชั่นที่ได้รับอนุญาต

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

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

เช่นเดียวกับนี้สามารถนำไปใช้กับ Rollups การโพสต์สถานะต่าง: zkSync Era และ zkSync Lite มีกระบวนการสามขั้นตอนในการโพสต์สถานะต่าง: ขั้นแรกพวกเขาจะส่งข้อมูลโดยไม่มีการพิสูจน์ใด ๆ จากนั้นพวกเขาก็จัดเตรียมการพิสูจน์ให้พวกเขา และจากนั้น หลังจากล่าช้า 24 ชั่วโมง รูทจะพร้อมใช้งานเพื่อดำเนินการเพื่อดำเนินการถอนเงิน ตามทฤษฎีแล้ว เมื่อมีการจัดเตรียมหลักฐาน ลำดับของธุรกรรมได้รับการแก้ไขแล้ว ดังนั้นจึงไม่จำเป็นต้องรอให้การดำเนินการล่าช้าผ่านไป ยกเว้น zkSync สามารถคืนค่าการบล็อกเหล่านั้นได้:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

แม้ว่าสำหรับ zkSync Era จะไม่มีการบล็อกกลับคืนมา แต่บน zkSync Lite มันเกิดขึ้น 8 ครั้ง

ความสามารถในการสังเกตขั้นสุดท้าย

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

ลองมาดูคำตอบบางส่วน:

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

คำตอบที่ฉันชอบ

แนะนำวิธีแก้ปัญหาที่ใช้งานได้จริงที่นี่:

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

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

ตัวชี้วัดความมีชีวิตชีวา

ในขั้นตอนแรกในการติดตามเวลาจนถึงขั้นสุดท้ายของการทำธุรกรรมแบบสะสม บน L2BEAT เราเริ่มติดตามตัวชี้วัดความมีชีวิตชีวา ในช่วงเวลาเฉพาะระหว่างชุดธุรกรรม (ถ้ามี) และรากของรัฐ เหตุผลก็คือ หากชุดรวมอัปเดตมีการโต้ตอบกับ L1 เพียงเดือนละครั้ง ผู้ใช้ไม่สามารถคาดหวังเวลาที่จะสิ้นสุดให้อยู่ในลำดับนาทีได้ การวัดความมีชีวิตชีวาสามารถถือเป็นตัวบ่งชี้ขอบเขตล่างสำหรับเวลาจนถึงขั้นสุดท้าย: ถ้าการรวบรวมข้อมูลธุรกรรมมีการลงรายการบัญชีชุดงานทุกๆ สองนาที และสมมติว่าการกระจายของธุรกรรม L2 มีความสม่ำเสมอ เวลาที่คาดไว้จนถึงขั้นสุดท้ายจะไม่ต่ำกว่าหนึ่งนาที .

นี่คือตัวอย่างข้อมูลที่เรากำลังติดตามสำหรับ zkSync Era (การอัปเดตสถานะ) และ OP Mainnet (แบตช์ tx):

ตัวชี้วัดความมีชีวิตชีวาของ zkSync Era สำหรับเดือนกันยายน

ตัวชี้วัดความสดของ OP Mainnet สำหรับเดือนกันยายน

ตามที่คาดการณ์ไว้ เนื่องจากการพิสูจน์ ZK ต้องใช้เวลาในการสร้างและมีแรงจูงใจที่จะรวมธุรกรรมมากขึ้นในการพิสูจน์เดียว zkSync Era จึงมีตัวชี้วัดความสดใหม่ที่แย่กว่า OP Mainnet สิ่งสำคัญคือต้องจำไว้ว่า ตามที่เราพูดคุยกันในส่วนที่แล้ว การวัดความมีชีวิตชีวาไม่ได้แปลโดยตรงไปสู่การพิจารณาขั้นสุดท้าย: ในกรณีที่เลวร้ายที่สุด OP Mainnet มีเวลาสูงกว่าในการสรุปผลจริง ๆ เนื่องจากมีหน้าต่างลำดับ

ตอนนี้คุณสามารถสำรวจตัวชี้วัดความมีชีวิตชีวาสำหรับ Rollups ส่วนใหญ่บน L2BEAT:

ข้อจำกัดของการติดตามความมีชีวิตชีวา

แม้ว่าความมีชีวิตชีวาจะมองว่าเป็นตัวบ่งชี้ขอบเขตล่างของขั้นสุดท้าย แต่บางครั้งอาจเป็นตัวบ่งชี้ที่แย่มาก ลองนึกภาพการสะสมด้วยเวลาบล็อก 4 วินาที ซึ่งหมายความว่าสำหรับแต่ละบล็อก Ethereum จะมี 3 บล็อกการสะสม หากผู้ดำเนินการโรลอัพโพสต์เพียงสองบล็อก L2 ต่อบล็อก L1 แม้ว่าจากมุมมองของ Ethereum การโรลอัพนั้นเกิดขึ้นจริงมาก มันก็จะตามหลังการยืนยันแบบนุ่มนวลของ L2 มากขึ้นเรื่อยๆ และเวลาถึงขั้นสุดท้ายก็จะแย่ลงเรื่อยๆ แม้ว่านี่จะเป็นสถานการณ์ที่รุนแรง แต่ก็เป็นสิ่งที่ Rollup จำเป็นต้องคำนึงถึง

ตัวอย่างเชิงปฏิบัติคือ Starknet: แม้ว่าเราจะสังเกตโดยเฉลี่ย 32 วินาทีระหว่างการอัปเดตสถานะ แต่เวลาที่จะสิ้นสุดจริง ๆ แล้วอยู่ใกล้ถึง 6 ชั่วโมง:

ที่มา: starkscan.co

นี่เป็นเพราะ Starknet เผยแพร่การอัปเดตรูทสถานะสำหรับแต่ละบล็อก L2 บน L1 อย่างไรก็ตาม ในการดำเนินการนี้ พวกเขาจะต้องอ้างอิงหลักฐานของ SHARP ซึ่งโดยทั่วไปจะโพสต์ประมาณ หนึ่งครั้งทุกๆ 30 นาที นอกจากนี้ การพิสูจน์เหล่านี้ยังอยู่หลังปลายโซ่ L2 ที่ยืนยันอย่างนุ่มนวลประมาณ 6 ชั่วโมง

การยืนยันที่นุ่มนวล

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

ซ้าย: การรับประกันทางเศรษฐกิจของ Starknet หากพวกเขาได้รับการยืนยันอย่างนุ่มนวลซึ่งมีกลไกการฟันอย่างเจ็บแสบ ขวา: มูลค่ารวมที่เสี่ยงต่อการถูกจัดระเบียบใหม่เมื่อเวลาผ่านไป

ดำเนินต่อไป

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

ข้อสงวนสิทธิ์：

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