แนะนำสกุลเงิน

วันนี้เราเห็นโปรเจ็กต์ที่เริ่มทดลองกับ Madara สำหรับ App Chain ของพวกเขาแล้ว Pragma, Kakarot, Mangata Finance และ Dojo เป็นเพียงตัวอย่างบางส่วนเท่านั้น ตราบใดที่เราเชื่อในอนาคตแบบ Multi-chain และพลังของ zk scaling เราจะเห็นเพียงโปรเจ็กต์เหล่านี้อีกมากมายในอนาคต อย่างไรก็ตาม จำนวน App Chain ที่เพิ่มขึ้นก็ทำให้เกิดคำถามเช่นกัน

1. การกระจายอำนาจ
2. ความสามารถในการประกอบ
3. ประสบการณ์การพัฒนา

ในโพสต์นี้ ฉันจะพยายามอธิบายปัญหาที่เกิดขึ้นเนื่องจากการมี App Chain จำนวนมาก และยังเป็นวิธีแก้ไขปัญหาที่เป็นไปได้ซึ่งฉันคิดว่าสวยงามและเหมาะสมที่สุดสำหรับ Madara และ Starknet หากคุณเชี่ยวชาญเรื่อง App Chains และ Share Sequencing เป็นอย่างดีแล้ว คุณสามารถข้ามไปที่ส่วน "เดี๋ยวก่อน มันเป็นแค่ Polkadot อีกครั้ง"

จะเกิดอะไรขึ้นที่ 100 App Chains?

สมมติว่าเราอยู่ในอนาคตที่ตอนนี้เรามี App Chains ที่แตกต่างกันกว่า 100 รายการบน Ethereum มาแก้ไขปัญหาทั้งหมดที่จะเกิดขึ้นกันเถอะ

การกระจายอำนาจแบบกระจัดกระจาย

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

ความสามารถในการประกอบ

ความสามารถในการรวมองค์ประกอบหมายถึงการโต้ตอบข้ามแอปเป็นหลัก บน Ethereum หรือ Starknet นี่หมายถึงการเรียกสัญญาใหม่ และโปรโตคอลอื่นๆ จะจัดการทุกอย่างเอง อย่างไรก็ตาม ด้วย App Chain สิ่งนี้จะยากขึ้นมาก กลุ่มแอปต่างๆ มีบล็อกและกลไกที่เป็นเอกฉันท์เป็นของตัวเอง ทุกครั้งที่คุณพยายามโต้ตอบกับ App Chain อื่น คุณจะต้องตรวจสอบอัลกอริธึมที่เป็นเอกฉันท์และการรับประกันขั้นสุดท้ายอย่างรอบคอบ จากนั้นจึงตั้งค่า cross-chain bridge (โดยตรงไปยัง chain หรือผ่าน L1) หากคุณต้องการโต้ตอบกับ App Chain 10 ตัวที่มีการออกแบบที่แตกต่างกัน คุณจะต้องทำ 10 ครั้งที่แตกต่างกัน

ประสบการณ์การพัฒนา

การแก้ปัญหาเพื่อการกระจายอำนาจและการเชื่อมโยงไม่ใช่เรื่องง่าย หากนี่เป็นข้อกำหนดสำหรับทุก App Chain ก็จะทำให้เป็นเรื่องยากมากสำหรับนักพัฒนา Smart Contract ปกติในการสร้าง App Chain ของตัวเอง นอกจากนี้ เนื่องจาก App Chain ทุกแห่งพยายามแก้ไขปัญหาเหล่านี้ด้วยวิธีของตนเอง ในไม่ช้า เราจะเห็นมาตรฐานที่แตกต่างกันตามมาด้วย Chain ที่แตกต่างกัน ทำให้การเข้าร่วมระบบนิเวศทำได้ยากยิ่งขึ้น

ซีเควนเซอร์ที่แชร์สามารถแก้ปัญหานี้ได้

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

การกระจายอำนาจที่ใช้ร่วมกัน

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

คุณทำไม่ได้!

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

1. กลไกการสั่งซื้อ: มีหน้าที่รับผิดชอบในการเรียงลำดับธุรกรรมในคำสั่งซื้อเฉพาะ เมื่อคำสั่งซื้อนี้ได้รับการตัดสินใจโดยกลไกการสั่งซื้อแล้ว จะต้องปฏิบัติตาม สิ่งนี้บังคับใช้โดยการยอมรับคำสั่งซื้อนี้ใน L1 และบังคับให้ผู้ตรวจสอบ L1 ตรวจสอบว่าธุรกรรมได้รับการดำเนินการในคำสั่งซื้อที่ต้องการหรือไม่
2. Rollup Engine: โดยพื้นฐานแล้ว Rollup Engine คือทุกสิ่งทุกอย่างที่ Rollup ทำ - รวบรวมธุรกรรมจากผู้ใช้ ดำเนินการ สร้างการพิสูจน์ และอัปเดตสถานะบน L1 ตามหลักการแล้ว สิ่งนี้สามารถแบ่งออกเป็นองค์ประกอบต่างๆ ได้มากขึ้น แต่เราจะหลีกเลี่ยงสิ่งนั้นสำหรับโพสต์นี้

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

โดยทั่วไปแล้วซีเควนเซอร์ที่ใช้ร่วมกันจะสั่งธุรกรรมข้ามโรลอัพและส่งมอบให้กับ L1 ดังนั้น โดยการกระจายอำนาจชุดซีเควนเซอร์ที่ใช้ร่วมกัน คุณจะกระจายอำนาจโรลอัพทั้งหมดที่เชื่อมโยงกับชุดซีเควนเซอร์นั้น! หากต้องการทราบแนวคิดโดยละเอียดเพิ่มเติมเกี่ยวกับการทำงานของซีเควนเซอร์ที่ใช้ร่วมกัน คุณสามารถดู <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> บทความ 17 ที่น่าทึ่งนี้โดย Espresso

ความสามารถในการประกอบ

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

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

ประสบการณ์ของนักพัฒนา

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

ต่อไปนี้คือแผนภาพที่แสดงว่า App Chain มีลักษณะอย่างไรพร้อมกับซีเควนเซอร์ที่แชร์

เดี๋ยวก่อน มันเป็นแค่ลายจุดทั้งหมดอีกครั้ง

Polkadot เริ่มทำงานเกี่ยวกับอนาคตของ multi-chain ก่อน Ethereum พวกเขาทำงานเกี่ยวกับมันมามากกว่า 5 ปีแล้ว และถ้าคุณคุ้นเคยกับ Polkadot คุณอาจสังเกตเห็นว่าการออกแบบข้างต้นเป็นการประดิษฐ์สิ่งต่างๆ มากมายที่ Polkadot ได้ทำไปแล้วขึ้นมาใหม่!

The Relay Chain (การกระจายอำนาจที่ใช้ร่วมกัน)

โดยพื้นฐานแล้วห่วงโซ่รีเลย์นั้นเป็นเอ็นจิ้นการสั่งซื้อ + L1 ในแผนภาพลำดับด้านบน โซ่รีเลย์

1. สั่งซื้อธุรกรรมข้าม Parachains ทั้งหมด (โรลอัพ)
2. ตรวจสอบธุรกรรมที่ดำเนินการอย่างถูกต้อง (แทนที่จะตรวจสอบ zk จะเรียกใช้โค้ดการดำเนินการของการยกเลิกอีกครั้งเพื่อตรวจสอบสถานะที่ต่างกัน)

คุณอาจรู้ว่ารีเลย์นั้นเป็นซีเควนเซอร์ที่ใช้ร่วมกันที่เรากล่าวถึงข้างต้น ยกเว้นความจริงที่ว่ารีเลย์เชนยังจำเป็นต้องตรวจสอบการดำเนินการด้วย (เนื่องจาก Polkadot คือ L1) ในขณะที่เราปล่อยให้สิ่งนั้นเป็นของ Ethereum

XCM และ XCMP

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

อย่างที่คุณอาจเดาได้ Polkadot ได้ทำสิ่งนี้ไปแล้ว XCM คือรูปแบบข้อความ และ XCMP คือโปรโตคอลข้อความที่ห่วงโซ่วัสดุพิมพ์ทั้งหมดสามารถใช้เพื่อสื่อสารระหว่างกัน ฉันจะไม่ลงรายละเอียดแต่คุณสามารถอ่านได้ ที่นี่ 5

สารตั้งต้นและคิวมูลัส

Substrate เป็นเฟรมเวิร์กที่พัฒนาโดย Parity ซึ่งสามารถใช้ในการสร้างบล็อกเชนได้ ในขณะที่พาราเชนทั้งหมดบน Polkadot ใช้ซับสเตรต แต่จริงๆ แล้วซับสเตรตนั้นถูกสร้างขึ้นด้วยวิธีไม่เชื่อเรื่องพระเจ้าแบบลูกโซ่ เฟรมเวิร์กสรุปแง่มุมทั่วไปทั้งหมดของบล็อกเชน เพื่อให้คุณสามารถมุ่งเน้นไปที่ตรรกะของแอปพลิเคชันของคุณ ดังที่เราทราบ Madara สร้างขึ้นบน Substrate เช่นเดียวกับ Polkadot, Polygon Avail และโปรเจ็กต์อื่นๆ อีกมากมาย นอกจากนี้ Cumulus ยังเป็นมิดเดิลแวร์ที่อยู่ด้านบนของ Substrate ที่ให้คุณเชื่อมต่อ chain ของคุณกับ Polkadot

ดังนั้นการเปรียบเทียบของเราต่อไปเหมือนเมื่อก่อน Substrate และ Cumulus ถือได้ว่าเป็นสิ่งทดแทนเฟรมเวิร์กแบบรวมที่ช่วยให้คุณสามารถสร้างกลุ่มแอปและเชื่อมต่อพวกมันกับซีเควนเซอร์ที่แชร์ได้

ซีเควนที่ใช้ร่วมกัน → รีเลย์เชน
ความสามารถในการประกอบ → XCM และ XCMP
เฟรมเวิร์กแบบโรลอัพ/สแต็ค → พื้นผิวและคิวมูลัส

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

ชำระ Polkadot บน Ethereum หรือไม่?

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

มี! อันที่จริงเราได้เริ่มต้นเรื่องนี้กับมาดาระแล้ว Madara ใช้เฟรมเวิร์ก Substrate เพื่อให้ใครก็ตามสามารถสร้างโซลูชัน L2/L3 ที่ขับเคลื่อนด้วย zk ของตนเองบน Ethereum ได้ สิ่งที่เราต้องการต่อไปคือห่วงโซ่รีเลย์ Polkadot ในรูปแบบของซีเควนเซอร์ที่ใช้ร่วมกัน โดยพื้นฐานแล้วถ้าเราสามารถนำรีเลย์ Polkadot กลับมาใช้ซ้ำได้

1. ลบส่วนการตรวจสอบตามที่เกิดขึ้นกับ L1 ผ่านการพิสูจน์ zk
2. ยืนยันลำดับของธุรกรรมกับ L1
3. ปรับโหนดและอัลกอริธึมที่เป็นเอกฉันท์ให้เหมาะสมเพื่อรองรับ Tendermint/HotStuff

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

1. กลุ่มนักพัฒนาที่กระตือรือร้นซึ่งยังคงสร้างและให้ความรู้แก่โลกเกี่ยวกับ Substrate
2. ชุดเครื่องมือสำหรับนักพัฒนาที่กระตือรือร้นและชุมชนที่เข้มแข็ง
3. Parachains ที่ใช้งานอยู่จำนวนมากสามารถเลือกที่จะชำระบน Ethereum ได้เช่นกันหากพวกเขาต้องการทำเช่นนั้น (เราเห็น Astar ทำเช่นเดียวกันกับ Polygon CDK เมื่อเร็วๆ นี้)

บทสรุป

แนวคิดหลักของฉันเบื้องหลังการเขียนโพสต์นี้คือการเปิดการสนทนาระหว่างระบบนิเวศที่กว้างขึ้นของ Starknet และ Ethereum ฉันรู้สึกว่าโมเดลการเรียงลำดับที่ใช้ร่วมกันจะมีบทบาทสำคัญในการกระจายอำนาจไม่เพียงแต่ Starknet เท่านั้น แต่ยังรวมไปถึง App Chain ทั้งหมดที่พิจารณาสร้างต่อยอดด้วย ตราบใดที่เรามั่นใจเกี่ยวกับวิทยานิพนธ์ของ App Chain และการปรับขนาด zk การวิเคราะห์โมเดลลำดับที่ใช้ร่วมกันอย่างละเอียดก็เป็นสิ่งที่หลีกเลี่ยงไม่ได้ ยิ่งไปกว่านั้น ในขณะที่ Madara กำลังก้าวไปสู่การผลิตและ Starknet ได้เริ่มทำงานเกี่ยวกับการกระจายอำนาจ ฉันรู้สึกว่าหัวข้อนี้เป็นสิ่งสำคัญที่ต้องพูดถึง ดังนั้น ฉันขอให้ทุกคนที่อ่านข้อความนี้แสดงความคิดเห็น/ข้อเสนอแนะที่คุณมีเกี่ยวกับหัวข้อนี้ รอคอยที่จะอ่านความคิดของคุณ!

ภาคผนวก

โพลคาด็อท vs คอสมอส

Cosmos ซึ่งคล้ายกับ Polkadot ได้รับการแก้ไขเพื่ออนาคตแบบ multi-chain มาหลายปีแล้ว เป็นผลให้มีการพัฒนามากมายด้วย Cosmos SDK และ IBC และเรายังเห็นกลุ่มแอปจำนวนมากที่สร้างอยู่เหนือระบบนิเวศของ Cosmos ดังนั้นจึงเป็นเรื่องยุติธรรมที่จะพิจารณา Cosmos ด้วยสำหรับแนวทางนี้ มุมมองส่วนตัวของฉันในหัวข้อนี้คือ Polkadot มีความเกี่ยวข้องมากกว่าเนื่องจากแก้ปัญหาซีเควนเซอร์ที่ใช้ร่วมกัน ในขณะที่ Cosmos ต้องการให้แต่ละแอปเชนสร้างชุดตรวจสอบของตัวเอง ยิ่งไปกว่านั้น Substrate ยังถูกสร้างขึ้นด้วยวิธีไม่เชื่อเรื่องพระเจ้าแบบลูกโซ่เพื่อให้นักพัฒนาสามารถสร้างบล็อกเชนโดยไม่ต้องมีข้อสันนิษฐานเกี่ยวกับอัลกอริธึมที่เป็นเอกฉันท์หรือระบบนิเวศของ Polkadot นี่คือเหตุผลที่เราเลือกวัสดุพิมพ์สำหรับมาดาระ อย่างไรก็ตาม ประสบการณ์ของฉันกับ Cosmos นั้นมีจำกัด และอยากได้ยินเรื่องนี้เพิ่มเติมจากผู้ที่มีประสบการณ์มากกว่า! คุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับการเปรียบเทียบทั้งสองเครือข่าย ได้ที่นี่

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

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