ทีม Lattice ได้ประกาศ Redstone - L2 ใหม่ของพวกเขาที่สร้างขึ้นโดยใช้การสนับสนุนใหม่ของพวกเขาใน OP Stack (สแต็กที่ขับเคลื่อน Optimism L2)

คำถามที่อยู่ในใจของทุกคนก็คือ “เกม onchain ควรถูกสร้างขึ้นบน L2 นี้หรือไม่ และจะเปรียบเทียบกับเกมอื่น ๆ ได้อย่างไร?” หลายๆ คนได้ติดต่อทีมของเราที่ Paima Studios เพื่อขอความเห็น เนื่องจากเราเป็นหนึ่งในผู้สร้างเกมออนไลน์ชั้นนำที่มีเกมถ่ายทอดสดบนหลายเครือข่าย ดังนั้น เราจะพยายามอย่างเต็มที่เพื่อเจาะลึกถึงความแตกต่างเล็กๆ น้อยๆ

บันทึก

ในขณะที่เขียน Redstone เพิ่งมีการประกาศเมื่อไม่นานมานี้ Web3 เป็นพื้นที่ที่เปลี่ยนแปลงไปอย่างรวดเร็ว ดังนั้นเราจึงขอแนะนำให้คุณอ่านโพสต์บนบล็อกนี้ด้วยใจที่เปิดกว้างต่อ Redstone เนื่องจากพวกเขาจะประกาศเพิ่มเติมเกี่ยวกับงานของพวกเขาอย่างหลีกเลี่ยงไม่ได้

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

ที่ซึ่งทุกอย่าง​เริ่มต้นขึ้น​

คุณต้องการสร้างเกม onchain หรือไม่? เมื่อพิจารณาว่า Redstone เป็น Ethereum L2 เราจะถือว่าคุณได้ตั้งใจที่จะใช้ประโยชน์จาก Ethereum แล้ว

แล้วทำไมคุณไม่สามารถปรับใช้เกมของคุณกับ Ethereum โดยตรงได้? คุณอาจรู้ว่ามันเป็นเพราะมันมีค่าใช้จ่ายมากเกินไป (มากกว่า >$1 ต่อการย้ายเกมในขณะที่เขียน) แต่คุณรู้ไหมว่าทำไมมันถึงแพงเกินไป? ปรากฎว่ามีค่าใช้จ่ายหลักสองประการ: ค่าใช้จ่ายในการดำเนินการ และค่าใช้จ่ายในการจัดเก็บข้อมูล - ทั้งสองอย่างนี้มีราคาแพงมากสำหรับเกม อย่างไรก็ตาม เช่นเดียวกับที่ CPU มีราคาแพงกว่าฮาร์ดไดรฟ์ ค่าใช้จ่ายในการดำเนินการจะสูงกว่าต้นทุนพื้นที่จัดเก็บข้อมูลอย่างมาก แล้วถ้าเราสามารถคิดหาวิธีแปลงต้นทุนการดำเนินการเป็นต้นทุนพื้นที่จัดเก็บได้ล่ะ ข่าวดี: Rollups ทำสิ่งนี้ทุกประการ

Rollups เป็น​โซลูชัน​การปรับขนาด

การโรลอัปมีหลายรูปแบบ โดยแต่ละรูปแบบจะแปลงต้นทุนการดำเนินการเป็นต้นทุนพื้นที่จัดเก็บในลักษณะของตนเอง:

1. โรลอัปในแง่ดี: รันการคำนวณแบบออฟไลน์ จากนั้นจัดเก็บข้อมูลทั้งหมดที่จำเป็นในการดำเนินการฟังก์ชัน (เฉพาะข้อมูล ไม่มีการดำเนินการ) พร้อมกับค่าที่คำนวณในเครื่องของคุณสำหรับผลลัพธ์ ดำเนินการจริงเฉพาะในกรณีที่มีคนเชื่อว่าผลลัพธ์ที่คุณโพสต์นั้นไม่ถูกต้อง (“หลักฐานการฉ้อโกง”) \
   ตัวอย่างยอดนิยม: Arbitrum, การมองโลกในแง่ดี
2. โรลอัพ ZK: รันการคำนวณแบบออฟไลน์ จากนั้นจัดเก็บข้อมูลทั้งหมดที่จำเป็นในการดำเนินการฟังก์ชัน (เฉพาะข้อมูล ไม่มีการดำเนินการ) พร้อมด้วยหลักฐาน ZK ที่คำนวณในเครื่องของคุณเพื่อดูผลลัพธ์ \
   ตัวอย่างยอดนิยม: ZK Sync, Starknet, Polygon zkEVM
3. Sovereign rollup: รันการคำนวณแบบ offchain จากนั้นจัดเก็บข้อมูลทั้งหมดที่จำเป็นในการดำเนินการฟังก์ชัน (เพียงข้อมูล ไม่มีการดำเนินการ) \
   ตัวอย่างยอดนิยม: Rollkit, Paima Engine

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

การลดต้นทุนของ​L2s​

เห็นได้ชัดว่าการลดต้นทุนของ L2 เหล่านี้เป็นกุญแจสำคัญในการประสบความสำเร็จในเกม แม้ว่าการโรลอัพจะมีราคาถูกลงอย่างแน่นอน (คอมพิวเตอร์เริ่มดีขึ้น เทคโนโลยี ZK ก็ดีขึ้น ฯลฯ) ต้นทุนหลักไม่ได้รันการคำนวณแบบออฟเชน แต่เป็นต้นทุนในการโพสต์ข้อมูลไปยัง L1

เพื่อแก้ไขปัญหานี้ Ethereum จะแนะนำวิธีใหม่ในการจัดเก็บข้อมูลที่ราคาถูกกว่ามาก (เรียกว่า EIP4844) โดยที่ข้อมูลจะถูกจัดเก็บเพียงชั่วคราวเท่านั้น (ในทางปฏิบัติคือ ~2 สัปดาห์ เพื่อให้นานพอสำหรับการโพสต์หลักฐานการฉ้อโกงและ เพื่อให้ข้อมูลถูกจำลองโดยโหนดทั่วโลก)

EIP4844 มาพร้อมกับข้อเสียบางประการ:

• ข้อมูลเป็นเพียงชั่วคราว (คุณจะต้องค้นหาโซลูชันการจัดเก็บข้อมูลอื่นเพื่อโฮสต์ในภายหลัง)
• ข้อมูลมีจำกัด โดยจำกัดไว้ที่ประมาณ 2 MiB ต่อบล็อก (แชร์ระหว่างการโรลอัพทั้งหมดบน Ethereum)

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

ทางเลือก #1: จัดเก็บข้อมูลบนเซิร์ฟเวอร์ส่วนกลาง (หรือชุดเซิร์ฟเวอร์ )

ทางเลือกหนึ่งในการรักษาต้นทุนให้ต่ำก็คือเพียงจัดเก็บข้อมูลไว้ในเซิร์ฟเวอร์ส่วนกลางที่ผู้คนไว้วางใจให้คุณดำเนินการ และโพสต์เฉพาะแฮชของข้อมูลบนเชนเท่านั้น แนวคิดที่แตกต่างออกไปคือการใช้กลุ่มของเครื่องที่ดำเนินการอย่างอิสระซึ่งรวมกันเป็น multisig โครงการดังกล่าวเรียกว่า “คณะกรรมการความพร้อมใช้งานของข้อมูล” (DAC) และนี่คือสิ่งที่ Arbitrum Nova, Arbitrum Orbit และ Polygon CDK ใช้

แผนการเหล่านี้มีราคาถูกกว่ามาก ($0.001 / tx สำหรับ Arbitrum Nova หากคุณเพิกเฉยต่อตลาดค่าธรรมเนียม) เพื่อแลกกับการที่เครือข่ายถูกรวมศูนย์มากขึ้น ความเสี่ยงหลักคือหาก DAC หยุดโฮสต์ข้อมูลทุกครั้ง (เช่น โพสต์แฮชและไม่แชร์ข้อมูลสำหรับแฮชนั้น) เครือข่ายจะหยุดทำงาน

หมายเหตุพิเศษเกี่ยวกับ​Arbitrum​

คุณอาจสงสัยว่าเหตุใด Arbitrum จึงปรากฏสองครั้งในรายการ Arbitrum นำเสนอ 3 ข้อเสนอหลักในขณะนี้:

• Arbitrum One (เครือข่าย Arbitrum หลักซึ่งเป็นการรวมข้อมูลเต็มรูปแบบบน Ethereum)
• Arbitrum Nova (L2 ที่ใช้ DAC)
• Arbitrum Orbit (สแต็กเพื่อสร้าง L3 สำหรับ Arbitrum One)

อย่างที่คุณเห็น ปัญหาของ Nova ก็คือไม่มีวิธีที่ดีในการใช้ประโยชน์จาก DeFi สำหรับเกมของคุณ (ผู้ใช้จะต้องไปที่ (Nova -> ETH L1 -> One) และใช้เงินจำนวนมากไปกับการเติมน้ำมันเพื่อเชื่อมต่อ) ในขณะที่ Orbit stack ใหม่ช่วยให้คุณไปได้อย่างง่ายดาย (Orbit -> One) นอกจากนี้ เนื่องจาก Orbit เป็นสแต็คสำหรับการสร้าง L3 คุณสามารถใช้ L3 ที่มีอยู่ได้ เช่น Xai Games ที่ขับเคลื่อน DAC ของตัวเอง หรือหมุน L3 ของคุณเอง (แม้ว่าคุณจะมี L3 เฉพาะเกมที่มีการโพสต์การเชื่อมต่อกับ Ethereum เป็นครั้งคราวเท่านั้น แฮชคุณอาจจะดีกว่าด้วย web2.5)

ทางเลือก #2: จัดเก็บข้อมูลใน​เครือข่าย​กระจายอำนาจอื่น

แทนที่จะรอให้ EIP4844 ถูกนำมาใช้โดยมีแบนด์วิดธ์ที่จำกัดในเมนเน็ต โปรเจ็กต์อื่นๆ เช่น Celestia, Avail และ EigenDA ได้ตัดสินใจที่จะใช้แนวคิดที่คล้ายกันเป็นลูกโซ่ที่แยกจากกัน (เรียกว่าเลเยอร์ Data Availability (“DA”)) และโดยการเน้นไปที่เพียง ในกรณีการใช้งานนี้ พวกเขาเสนอขีดจำกัดข้อมูลที่สูงกว่าแผน Ethereum mainnet ที่จะรองรับเช่นกัน แพลตฟอร์มเหล่านี้ไม่รองรับสัญญาอัจฉริยะ แต่มีไว้เพื่อใช้เป็นชั้นข้อมูลสำหรับ L2 เท่านั้น

โดยเฉพาะอย่างยิ่ง คุณสามารถสร้าง OP Stack พร้อมข้อมูลเกี่ยวกับ Celestia รวมถึง Arbitrum Orbit พร้อมข้อมูลเกี่ยวกับ Celestia ได้เช่นกัน สิ่งนี้มาพร้อมกับข้อแลกเปลี่ยนบางประการ:

1. เชื่อมั่น. การเปลี่ยนแปลงของคุณตอนนี้ขึ้นอยู่กับเลเยอร์ DA เพื่อความปลอดภัยที่ด้านบนของ Ethereum (แต่อาจดีกว่า DAC)
2. ค่าใช้จ่าย. ตอนนี้ Rollup ของคุณจะต้องจ่ายเงินให้กับเครือข่าย DA เพื่อความปลอดภัย (ซึ่งคุณต้องจ่ายเป็นโทเค็นดั้งเดิมของเลเยอร์ DA)
3. ความเร็ว. เวลาบล็อกของ Celestia คือ 15 วินาที และเวลาบล็อกความพร้อมคือ 20 วินาที ตัวอย่างเช่น ข้อมูลจำเป็นต้องชำระให้กับ Celestia ก่อนจึงจะสามารถเชื่อมต่อกับ EVM ด้วย สัญญา blobstream ของ Celestia ได้ คำนึงถึงประเด็นนี้ด้วย เนื่องจาก L2 โดยทั่วไปจำลองเวลาบล็อกได้เร็วกว่าที่ Ethereum สามารถให้ได้ (เนื่องจากเวลาบล็อกของ Ethereum อยู่ที่ 15 วินาทีเท่านั้น แม้ว่า Arbitrum จะใช้เวลาบล็อกเร็วกว่านี้ก็ตาม)

การตั้งค่าประเภทนี้ใช้โดย Mantle (OP Stack + EigenLayer DA) และ Manta Pacific (OP Stack + Celestia) ค่าใช้จ่ายสำหรับสิ่งเหล่านี้ยังคงต้องรอดูกันต่อไป แต่ทีม Celestia อ้างว่า อยู่ที่ประมาณ 0.001 ดอลลาร์ ซึ่งหมายความว่าต้นทุนพื้นที่จัดเก็บบนเลเยอร์ DA (สัมพันธ์กับต้นทุนการดำเนินการจากตลาดค่าธรรมเนียมในฝั่ง EVM) นั้นน้อยมาก

ทางเลือก #3: จัดเก็บข้อมูลไว้ใน DAC ที่สามารถ​ท้าทายได้​

สุดท้ายนี้ เราสามารถพูดคุยเกี่ยวกับสิ่งที่ Redstone นำเสนอได้ หากคุณไม่ชอบการแลกเปลี่ยนกับการจัดเก็บข้อมูลบนเลเยอร์ DA แต่ไม่ชอบการรวมศูนย์ของ DAC คุณสามารถสร้าง DAC แทนซึ่งคุณสามารถลงโทษทางการเงินแก่คณะกรรมการได้ หากพวกเขาไม่ได้ทำให้ข้อมูลพร้อมใช้งาน .

เพื่อช่วยให้เข้าใจว่าสิ่งนี้หมายถึงอะไร เรามาดูขั้นตอนการทำงานของโปรโตคอล DAC กันดีกว่า:

วิธีเขียน​ข้อมูล​

1. Sequencer สำหรับ Redstone ได้รับธุรกรรมของคุณ
2. Sequencer ส่งข้อมูลไปยัง DAC ที่จะจัดเก็บ
3. DAC ส่งคืนการตอบรับว่าข้อมูลถูกเก็บไว้
4. Sequencer จะโพสต์แฮชของข้อมูลไปที่ L1

วิธีการอ่าน​ข้อมูล​

1. ซิงค์เครือข่าย Ethereum เพื่อค้นหาแฮชที่ส่งไปยังสัญญาการยกเลิก
2. ค้นหาข้อมูลสำหรับแฮชจาก DAC
3. คำนวณสถานะของ L2 ตามข้อมูลนี้

แล้ว Redstone จะ​เปลี่ยนแปลง​อะไร?

เมื่ออ่านข้อมูล หากไม่มีข้อมูล คุณสามารถท้าทาย DAC ได้โดยอ้างว่าไม่ได้ทำให้ข้อมูลพร้อมใช้งาน (หรือที่เรียกว่าข้อมูลไม่สามารถดาวน์โหลดได้จากเซิร์ฟเวอร์)

เพื่อจูงใจให้ทุกคนพูดตามตรง เราได้ตั้งกฎที่เข้มงวดดังต่อไปนี้:

1. หากผู้ท้าชิงไม่ซื่อสัตย์ (มีข้อมูลจริง) พวกเขาจะถูกเฉือน (ไม่เช่นนั้น คุณสามารถโจมตีเครือข่ายทางการเงินได้ด้วยการท้าทายทุกบล็อก)
2. หาก DCA ไม่ซื่อสัตย์ (ไม่มีข้อมูล) ก็จะถูกตัดออก

ดูเหมือนเป็นวิธีแก้ปัญหาง่ายๆ แต่ปัญหาอยู่ที่การรู้ว่าใครเป็นฝ่ายผิดหากเกิดปัญหาขึ้น ลองนึกถึงสถานการณ์ต่อไปนี้:

1. Sequencer โพสต์แฮชโดยไม่เปิดเผยข้อมูลจริง
2. มีคนท้าทายซีเควนเซอร์
3. ซีเควนเซอร์มองเห็นความท้าทายและทำให้ข้อมูลพร้อมใช้งาน

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

หากวิธีแก้ปัญหาของคุณคือสมมติว่าซีเควนเซอร์ไม่เคยโกหกแค่เกม ทำไมไม่ลองใช้ DAC มาตรฐานแทน นอกจากนี้ สมมติว่าซีเควนเซอร์มีความซื่อสัตย์ไม่ได้ประกอบอย่างดีกับแนวคิดของซีเควนเซอร์ที่ใช้ร่วมกัน “superchain” ซึ่งหมายความว่าสินทรัพย์ไม่สามารถใช้ซีเควนเซอร์ที่ใช้ร่วมกันเพื่อถ่ายโอนระหว่าง OP Stack chains (ดังนั้นคุณจึงประสบปัญหาเดียวกันกับ Arbitrum Nova เว้นแต่ Redstone ถูกปรับใช้เป็น L3)

วิธีที่ทีม Lattice วางแผนในการจัดการเรื่องนี้จะเป็นประเด็นสำคัญที่ต้องระวังเนื่องจากมีเอกสารประกอบและข้อมูลแผนการทำงานเพิ่มเติม

ทางเลือก #4: ใช้​ZK​

โปรดทราบว่าปัญหาเกี่ยวกับการไม่ได้แชร์ข้อมูล (การโจมตีด้วยการระงับข้อมูล) ที่ส่งผลต่อ Redstone นั้นไม่ได้เกิดขึ้นเฉพาะกับ Rollups Optimistic เท่านั้น ZK Rollups ซึ่งข้อมูลถูกจัดเก็บนอกเครือข่าย (เรียกว่า “Validiums”) ประสบปัญหาเดียวกัน ซึ่งเป็นเหตุผลว่าทำไมผู้คนจึงสนใจ Rollups มากกว่า (ซึ่งโพสต์ข้อมูลทั้งหมดไปยังลูกโซ่)

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

ฉันจะทำให้ต้นทุนสำหรับเกมของฉันลดลงได้อย่างไรหาก Solidity เป็นปัญหา ?

โพสต์ในบล็อกทั้งหมดนี้เราได้พูดคุยเกี่ยวกับวิธีจัดการต้นทุนพื้นที่จัดเก็บข้อมูล อย่างไรก็ตาม เกมบางเกมอาจมีการจำกัด CPU (แม้ว่าจะทำงานในระบบ EVM แบบรวมศูนย์ก็ตาม) หากเป็นคุณ คุณอาจสนใจใช้ Sovereign Rollup เพื่อให้คุณสามารถปรับขนาดเกมของคุณเกินขีดจำกัดของ EVM โดยใช้ Paima Engine

Paima Engine อนุญาตให้สร้างเครื่องสถานะเฉพาะแอปใน Javascript ที่คุณสามารถปรับใช้กับเชน EVM ใดก็ได้ที่คุณเลือก (รวมถึง Redstone ด้วย!) โรลอัพอธิปไตยเหล่านี้สามารถเข้าถึงข้อมูล EVM (รวมถึงข้อมูลเอ็นจิ้น MUD) และสามารถใช้เป็นวิธีที่ดีเยี่ยมในการทำให้ส่วนใดส่วนหนึ่งของเกมของคุณรันเร็วขึ้นและถูกลงมาก

​บทสรุป​

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

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

ไพมา​สตูดิ​โอ

Paima Studios ก่อตั้งขึ้นในเดือนเมษายน 2022 เป็นผู้พัฒนาหลักของ Paima Engine ซึ่งเป็นเอ็นจิ้น Web3 ที่สร้างขึ้นโดยใช้เทคโนโลยีเลเยอร์ 2 ใหม่ที่ช่วยให้สามารถสร้างเกมออนไลน์ การเล่นเกม และโลกอัตโนมัติได้ Paima Engine เป็นวิธีที่ปลอดภัยและง่ายดายในการเข้าสู่ Web3 เนื่องจากสามารถใช้กับทักษะ Web2 ได้ และไม่ทำให้ผู้ใช้หรือนักพัฒนาเผชิญกับความเสี่ยงและการแฮ็กทั่วไปของ Web3

• ฐานรหัส Paima Engine: https://github.com/PaimaStudios/paima-engine
• เอกสาร Paima: https://docs.paimastudios.com/
• เทมเพลต Paima: https://github.com/PaimaStudios/paima-game-templates
• แพ็คเกจ Paima NPM: <a href="https://www.npmjs.com/package/@paima/sdk""> https://www.npmjs.com/package/@paima/sdk

คุณสามารถเรียนรู้เพิ่มเติมจากโซเชียลมีเดียของเรา:

• ยูทูป: <a href="https://www.youtube.com/@paimastudios""> https://www.youtube.com/@paimastudios
• ดิสคอร์ด: http://discord.gg/jZ59ArVaxv
• เรดดิท: https://reddit.com/r/paima
• ทวิตเตอร์: https://twitter.com/PaimaStudios

อยากร่วมงานกันไหม? อย่าลังเลที่จะติดต่อเราผ่านหน้าติดต่อของเรา: https://paimastudios.com/contact/

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

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