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

วิทัลิกย้ำความสำคัญในบทความเร็ว ๆ นี้ว่า ความสามารถในการถอนสินทรัพย์จากเลเยอร์ 2 กลับสู่เลเยอร์ 1 อย่างราบรื่นเป็นตัวบ่งชี้ความปลอดภัยที่สำคัญมาก

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

เพื่อเพิ่มความรู้ให้กับผู้อ่านเกี่ยวกับความเสี่ยงด้านความปลอดภัยของชั้น Layer 2 "Geek Web3" จะใช้ Loopring Protocol V3 และ Arbitrum เป็นตัวอย่างในข้อความต่อไปนี้เพื่ออธิบายว่า "ฟังก์ชันการถอดออกที่ไม่จำกัดสิทธิ" เช่น ถอดออกแบบบังคับและทางหนีหนีเป็นองค์ประกอบที่ห้ามไม่ได้ของ Layer 2

(ตามข้อมูลจากเบราว์เซอร์ L2BEAT ของ dYdX จนถึงปัจจุบัน ฟังก์ชันการซื้อขาย/ถอนเงินบังคับของ dYdX ถูกใช้งานทั้งหมด 152 ครั้ง โดยมีการถอนเงินขนาดใหญ่เกินหนึ่งล้านดอลลาร์ 7 ครั้ง) การต้านการเซ็นเซอร์เป็นปัญหาใหญ่: ถ้าซีเควนเซอร์ปฏิเสธคำขอของคุณโดยเจตนา

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

กล่าวคือ ความสนใจของคนส่วนใหญ่มักเน้นไปที่ว่าการเปลี่ยนสถานะในชั้น Layer 2 มีประสิทธิภาพหรือไม่ ว่า Sequencers สามารถขโมยเหรียญได้หรือไม่ และว่ามีการใช้ระบบการพิสูจน์การทุจริต/ความถูกต้องหรือไม่ อย่างไรก็ตามพวกเขามักละเลยความเสี่ยงที่ไม่ควรมองข้าม: ถ้า Sequencer ปฏิเสธคำขอการทำธุรกรรมของคุณอย่างต่อเนื่อง หรือเกิดข้อบกพร่องเพียงช่วงเวลายาวนาน หรือแม้แต่ปิดตัวลง?

ควรทราบว่าระหว่างเวลาที่ Solana ล่มสลาย มีกรณีที่ผู้คนไม่สามารถเพิ่มหลักทรัพย์ในเวลาที่กำหนดเนื่องจากความเสี่ยงในการล่วงลอยของสินทรัพย์ 导致数百万美元的资产面临风险。 การปฏิเสธคำขอของผู้ใช้เช่นนี้อาจทำให้เกิดขาดทุนทางเศรษฐกิจสำคัญ

แม้แต่บางบุคคลก็อาจพบเจอสถานการณ์แบบนี้ ถ้ามันเกิดขึ้นกับ 'ปลาวาฬ' บางคนที่ถือมีจำนวนเงินมาก ตลอดทั้งตลาดอาจประสบความเสียหาย ตัวอย่างเช่น สมมติให้มีคนหนึ่งที่มีทรัพย์สินมูลค่าร้อยล้านดอลลาร์ในโปรโตคอลการให้ยืมดิจิทัลบนเอเธอเรียม ต้องเผชิญกับการเลิกประทุษร้ายในอีก 1 อาทิตย์ แต่ถูกลงโทษโดย OFAC เนื่องจากใช้ Tornado ส่วนใหญ่ของเงินของพวกเขาอยู่บน Optimism (OP) และ OP Sequencer ซึ่งปฏิบัติตามกฎหมาย OFAC ปฏิเสธคำขอของพวกเขา

มาฉายภาพปัญหานี้บนบล็อกเชนอิสระเช่น Avalanche หรือ Polygon แยกจาก Ethereum หากโหนดฉันทามติของ Validator มากกว่าสองในสามของ Avalanche ตัดสินใจที่จะดําเนินการตรวจสอบธุรกรรมกับคุณพวกเขาสามารถปฏิเสธที่จะรวมธุรกรรมของคุณไว้ในบล็อกหรือปฏิเสธการรับรู้บล็อกที่มีธุรกรรมของคุณ ในกรณีนี้เงินของคุณจะถูกฝังอยู่ในห่วงโซ่นี้เป็นหลักและไม่สามารถถอนได้:

น้อยกว่าสองในสาม

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

ดังนั้นปัญหานี้จะได้รับการแก้ไขได้อย่างไร? พูดง่ายๆคือเราจะใช้ฟังก์ชันการถอนแบบ 'ไม่ได้รับอนุญาต' ที่ช่วยให้ผู้ใช้สามารถดึงสินทรัพย์ของพวกเขากลับไปที่เลเยอร์ 1 ได้อย่างปลอดภัยแม้ว่าจะอยู่ภายใต้การตรวจสอบโดย Sequencer หรือทีมโครงการ Layer 2 ก็ตาม ทีมโครงการบางคนได้เสนอแนวคิดของซีเควนเซอร์แบบกระจายอํานาจ แต่นี่เป็นวิธีแก้ปัญหาผิวเผิน หากซีเควนเซอร์จํานวน จํากัด เหล่านี้สมรู้ร่วมคิดในการตรวจสอบคุณพวกเขายังคงสามารถ 'แช่แข็ง' ทรัพย์สินของคุณได้ นอกจากนี้ปัญหาของการโจมตีต่อต้าน Sybil ในโหนด Proof of Stake (PoS) ก็เป็นปัญหาเช่นกัน (ดังที่เห็นในเหตุการณ์ Multichain)

วิธีที่มีประสิทธิภาพที่สุดคือการติดตั้ง 'exit' ที่มีประสิทธิภาพบนบล็อกเชน Layer 1 ที่อนุญาตให้ผู้ใช้ถอนเงินของพวกเขาจาก Layer 2 ผ่านทางเข้า L1 นี้ในกรณีที่พวกเขาไม่ได้รับการตอบกลับจาก Sequencer เป็นระยะเวลายาว

ในบริบทของโปรโตคอล Loopring เวอร์ชัน 3 มันระบุสองสถานการณ์ที่แตกต่างกันสำหรับการถอนเงินแบบบังคับที่ผู้ใช้เริ่มต้น สถานการณ์แรกคือดังนี้:

ผู้ใช้สามารถเริ่มการถอนแบบบังคับโดยตรงบน Layer 1 โดยใช้ฟังก์ชัน forcedWithdraw ในสัญญา ExchangeV3 พวกเขาต้องประกาศว่าบัญชี Layer 2 ของพวกเขาอยู่ในโปรโตคอล Loopring และเหรียญที่พวกเขาต้องการถอน ตามมานั้น สัญญา ExchangeV3 จะสร้างเหตุการณ์บล็อกเชน ซึ่งเป็นสัญญาณว่ามีคนได้เริ่มขอการถอนแบบบังคับ โดยเนื่องจากทุกโหนดในโปรโตคอล Loopring รวมถึง Sequencer ทำงานด้วยไคลเอนต์ Geth พวกเขาจะได้รับข้อมูลเกี่ยวกับการถอนแบบบังคับและเหตุการณ์บล็อกเชนที่เกี่ยวข้องจากข้อมูลบล็อก Ethereum

สำคัญที่จะระบุว่าการถอนแบบบังคับไม่ได้รับการประมวลผลทันที แต่ถูกวางไว้ในคิว pendingForcedWithdrawals รอการประมวลผล หลังจากที่ตรวจสอบเห็นถึงการถอนแบบบังคับที่เริ่มต้นขึ้นบน Layer 1 ซีเควนเซอร์มักจะกระตุ้นฟังก์ชัน Process ในสัญญา ExchangeV3 ภายใน 15 วัน ฟังก์ชันนี้ทำการโอนโทเคนบนโซ่ Ethereum ไปยังผู้เริ่มถอนเงิน (จากที่เก็บเงินของโครงการ Layer 2 บนโซ่ Ethereum ไปยังผู้ถอนเงิน)

หากตัว Sequencer ไม่สามารถตอบสนองคำขอการถอนเงินที่บังคับของผู้ใช้ภายใน 15 วัน ผู้ใช้สามารถเรียกใช้ฟังก์ชัน notifyForcedRequestTooOld การกระทำนี้จะเรียกใช้สัญญา ExchangeV3 ให้ส่งออกเหตุการณ์ที่มีชื่อว่า WithdrawalModeActivated เพื่อแจ้งให้ทราบถึงโหนดทั้งหมดในโปรโตคอลของ Loopring ว่าโหมดการขายล่วงหน้าในกรณีล้มละลายได้ถูกเปิดใช้งานแล้ว

หากโหมดการล้างจำหน่ายในกระบวนการขั้นตอนถูกเปิดใช้งาน Loopring Protocol V3 จะหยุดรับบล็อก L2 ใหม่ที่ถูกส่งเข้ามาโดย Sequencer ซึ่งหมายความว่า Loopring Protocol ทั้งหมดจะหยุดทำงานในเวลานี้ กระบวนการนี้จะใช้เวลาอย่างน้อย 30 วัน

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

บทความนี้อธิบายถึงรูปแบบการชําระบัญชีล้มละลายของ Loopring Protocol ซึ่งเรียกอีกอย่างว่ากลไก "Escape Hatch" บน L2BEAT โมเดลนี้ถูกเรียกใช้ภายใต้เงื่อนไขบางประการ เช่น เมื่อซีเควนเซอร์ไม่สามารถตอบสนองต่อคําขอถอนเงินที่ถูกบังคับของผู้ใช้ภายในเวลาที่กําหนด หรือหากซีเควนเซอร์ประสบกับความผิดปกติหรือการปิดระบบในระยะยาว ในกรณีเช่นนี้ผู้ใช้สามารถเรียกใช้กระบวนการที่ทําให้สัญญา Rollup เข้าสู่สถานะแช่แข็งหรือหยุดชะงักได้ด้วยตนเอง จากนั้นผู้ใช้สามารถสร้าง Merkle Proof เพื่อแสดงสถานการณ์สินทรัพย์ของพวกเขาในเลเยอร์ 2 และถอนส่วนของสินทรัพย์ออกจากที่อยู่เงินฝากของโครงการเลเยอร์ 2 ในเลเยอร์ 1

ในเอกสาร StarkEx มีแผนภาพที่ระบุกระบวนการนี้โดยเฉพาะ หากคำขอ Forced Withdrawal ของผู้ใช้ Layer 2 ที่ส่งใน Layer 1 ไม่ได้รับการตอบกลับจาก sequencer ภายในช่วงเวลา 7 วัน ผู้ใช้สามารถเรียกใช้ฟังก์ชันการขอแช่แข็งเพื่อเริ่มต้นระยะเวลาการแช่แข็งสำหรับ Layer 2 ระหว่างระยะเวลานี้ sequencer ของ Layer 2 ไม่สามารถอัปเดตสถานะของ Layer 2 ใน Layer 1 สถานะที่แช่แข็งของ Layer 2 อยู่เป็นเวลาหนึ่งปีก่อนที่จะถูกแก้ออก หลังจากนั้นผู้ใช้สามารถส่ง Merkle proof และถอนเงินของพวกเขา

แต่เพื่อสร้างพิสูจน์ Merkle คนต้องได้รับ state tree L2 ทั้งหมดก่อนซึ่งหมายความว่าต้องได้รับข้อมูลจาก full node L2 เพื่อสร้างพิสูจน์ Merkle ต้องใช้รหัสโค้ดเฉพาะที่จำเป็นเพื่อสร้างพิสูจน์ Merkle โดยชัดเจนโดยนำเสนอระดับขั้นบางอย่างของข้อจำกัดทางเทคนิค ในการสะดวกสบายสำหรับส่วนใหญ่ของผู้ใช้ L2BEAT ได้กล่าวไว้ก่อนหน้านี้ว่า Layer 2 ควรตั้ง batch ของ full node ที่สามารถเข้าถึงได้และเปิดเป็น open-source เพื่อช่วยให้ผู้ใช้ได้รับสถานะของบัญชีทั้งหมดบน L2 (รวมถึงยอดคงเหลือ จำนวนธุรกรรม ฯลฯ) การเคลื่อนไหวนี้ยังย้ำถึงความสำคัญของการถอนบังคับและกลไก escape hatch

คุณสมบัติ 'การรวมธุรกรรมบังคับ' ของ Arbitrum

อย่างไรก็ตาม การถอน/ผู้เยี่ยมชมที่ถูกบังคับใช้โดยไม่ต้องการไม่ใช่วิธีการป้องกันการเซ็นเซอร์. เช่นเดียวกัน Arbitrum ใช้วิธี 'การรวมธุรกรรมที่ถูกบังคับ' โดยผู้ใช้สามารถส่งธุรกรรม/การถอนที่ต้องการให้ Sequencer ประมวลผลสู่สัญญา Inbox ที่ถูกเลื่อนไปก่อนที่ Layer 1 (L1) หาก Sequencer ไม่สามารถประมวลผลธุรกรรมเหล่านั้นภายใน 24 ชั่วโมงผู้ใช้สามารถเรียกใช้ฟังก์ชันการรวมเข้าบังคับที่สัญญา Inbox ของ L1 Sequencer ซึ่งจะทำให้ธุรกรรมถูกรวมเข้าไปโดยตรงในลำดับธุรกรรมของ Arbitrum (โดยการสร้างเหตุการณ์บนเชื่อมโยงที่แจ้งให้โหนด Arbitrum รู้ว่ามีการรวบรวมธุรกรรมหลายรายการบน Inbox ที่ถูกเลื่อนไปต้องถูกเพิ่มเข้าไปในบัญชี L2)

บทความนี้พูดถึงวิธีการที่โปรโตคอลบล็อกเชนต่างๆ ใช้ในการจัดการธุรกรรมโดยเน้นที่ Arbitrum เปรียบเทียบกับ Loopring และ StarkEx นี่คือการแปลคำว่า

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

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

โดยเฉพาะอย่างยิ่ง 'ธุรกรรมที่ต้องการการรวมกัน' จะต้องได้รับการยอมรับจากโหนด挑战者ของ ARB อย่างน้อยหนึ่งโหนด ณ ปัจจุบันมีโหนดเหล่านี้เป็นจำนวนเก้าเครื่อง และพวกเขามีอำนาจในการตัดสินใจว่าข้อความระหว่าง L2 และ L1 ที่เหมาะสมต้องการอนุมัติ และพวกเขายังเป็นผู้เดียวที่สามารถออก fraud proofs หากเกิดการร่วมกันของเครื่องเหล่านี้เป็นกันเอง นั้นเขาอาจยกเลิกธุรกรรม 'บังคับ' ของผู้ใช้ได้ทฤษฎี

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

ตามข้อมูลจาก L2BEAT ณ ปัจจุบัน แพลตฟอร์ม Layer 2 (L2) ที่มี Total Value Locked (TVL) เกิน 50 ล้าน USD และไม่มีมาตรการในการแก้ไข Sequencer Failure หรือ Proposer Failure รวมถึง OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM และ Metis แพลตฟอร์ม L2 เหล่านี้ในกรณีสุดขั้วอาจทำให้สินทรัพย์ของผู้ใช้ถูกแช่และไม่สามารถถอนได้จาก L2

ดังนั้นจึงเห็นได้ชัดว่าความจําเป็นสําหรับกลไกเช่นการบังคับถอนเงินหรือโหมดการชําระบัญชีล้มละลายมีอยู่ แม้ว่าในปัจจุบันพวกเขาพึ่งพาทฤษฎีเกมระหว่างผู้ใช้และผู้คัดแยก (ผู้ผลิตคําสั่งซื้อ) เป็นหลักและไม่สามารถพิจารณาได้ว่า "ถอนได้ตลอดเวลา" อย่างแท้จริง (Arbitrum มีความล่าช้า 24 ชั่วโมงซึ่งอาจล้มเหลว Loopring มีความล่าช้าสูงสุด 15 วัน StarkEx มีความล่าช้าสูงสุด 7 วัน) การมีกลไกเหล่านี้ดีกว่าการไม่มีเลย ปัญหาความล่าช้าในการบังคับถอนเงินอาจได้รับการแก้ไขในอนาคตด้วยการออกแบบกลไกที่ซับซ้อนมากขึ้น การออกแบบในปัจจุบันคํานึงถึงการใช้ประโยชน์จาก MEV (Maximal Extractable Value) ที่อาจเกิดขึ้นผ่าน forceInclusion ซึ่งจําเป็นต้องมีการแนะนําความล่าช้า สําหรับรายละเอียดเพิ่มเติมควรปรึกษาเอกสารอย่างเป็นทางการจากโครงการ L2 ต่างๆ

ด้วยการรวม Sequencers แบบกระจายอํานาจที่เพิ่มขึ้นในแผนงาน L2 จํานวนมากและความพยายามอย่างต่อเนื่องของหน่วยงานต่างๆเช่น Ethereum Foundation ซึ่งนําโดย Vitalik Buterin เพื่อให้ความรู้แก่ผู้คนเกี่ยวกับความปลอดภัยของเลเยอร์ 2 คุณสมบัติต่างๆเช่นฟังก์ชั่นธุรกรรมต่อต้านการเซ็นเซอร์ในการถอนแบบบังคับมีแนวโน้มที่จะได้รับความสนใจมากขึ้น สิ่งนี้จะทําให้ระบบนิเวศ Ethereum Layer 2 เข้าใกล้โครงสร้างพื้นฐานทางการเงินที่ทนต่อการเซ็นเซอร์และลดความน่าเชื่อถือ หากเลเยอร์ 2 บรรลุวิธีการเคลื่อนย้ายเงินทุนเข้าและออกที่ลดความน่าเชื่อถือคาดว่าผู้ดูแลสภาพคล่องและผู้ให้บริการสภาพคล่องจะเข้าสู่โครงสร้างพื้นฐาน L2 มากขึ้นผลักดันก้าวไปสู่การยอมรับ web3 จํานวนมาก

Disclaimer：

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