ของหน้าที่ดีที่สุดของ Rusty Russell ที่ถูกพิจารณาเป็นเส้นทางการพัฒนาบิทคอยน์

บล็อคยูนิคอร์นโน้ต: Rusty Russell เป็นนักพัฒนาที่ทำงานอย่างใกล้ชิดในชุมชนบิตคอยน์และได้รับความเคารพอย่างสูงภายในนั้น ท่านมีส่วนร่วมอย่างมีคุณค่าในการพัฒนาเคอร์เนล Linux และได้เข้าร่วมในโครงการพัฒนา Bitcoin Core ต่าง ๆ อย่างที่น่าประทับใจ

เมื่อ Bitcoin ถูกออกแบบเริ่มแรก มันได้รวมภาษาสคริปต์ที่สมบูรณ์เพื่อรองรับและสนับสนุนกรณีการใช้งานทางด้านความปลอดภัยที่ผู้ใช้อาจเสนอในอนาคต ตามที่ Satoshi Nakamoto กล่าวไว้ก่อนหายไป:

"ธรรมชาติของ Bitcoin เป็นเช่นนั้นเมื่อเวอร์ชัน 0.1 ถูกปล่อยออกมาการออกแบบหลักก็ถูกกําหนดไว้ในหินตลอดอายุการใช้งาน ด้วยเหตุนี้ฉันจึงต้องการออกแบบเพื่อรองรับธุรกรรมทุกประเภทที่ฉันคิดได้ แต่ในเวอร์ชันต่อมาเราได้ลบความสามารถในการเรียกใช้สคริปต์โดยพลการ ปัญหาคือทุกคุณสมบัติต้องการรหัสสนับสนุนพิเศษและฟิลด์ข้อมูลไม่ว่าจะใช้หรือไม่ก็ตามซึ่งนําไปสู่กรณีพิเศษมากเกินไป วิธีแก้ปัญหาคือสคริปต์ซึ่งสรุปปัญหาเพื่อให้ธุรกรรมสามารถอธิบายเงื่อนไขของพวกเขาในลักษณะที่เฉพาะเจาะจงสําหรับพวกเขาและโหนดเครือข่ายสามารถประเมินและตรวจสอบเงื่อนไขเหล่านี้ได้" - Satoshi Nakamoto, 17 มิถุนายน 2010

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

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

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

ตั้งแต่นั้นเป็นต้นมา การอัพเกรด Bitcoin ทุกครั้งก็เป็นการปรับปรุงคุณลักษณะที่เหลืออยู่ในที่สุด แก้ไขข้อบกพร่องที่ไม่ร้ายแรงอื่น ๆ ที่ Satoshi Nakamoto ทิ้งไว้ให้เรา และขยายฟังก์ชันของ subset ของสคริปต์ที่เหลืออยู่

การกู้คืนสคริปที่ยอดเยี่ยม

ในงานสัมมนา Bitcoin++ ที่ออสตินในต้นเดือนพฤษภาคม นักพัฒนาระบบ Lightning Network หลัก Rusty Russell ได้提出ข้อเสนอที่น่าตกใจมากในการพูดคุยครั้งแรกของเขาในงานสัมมนา โดยเขาพื้นฐานแล้วได้提议ให้เปิดใช้งานโค้ด opcodes ส่วนใหญ่ที่ถูกปิดใช้งานโดย Satoshi Nakamoto ก่อนหายตัวในปี 2010

ตั้งแต่การเปิดใช้งาน Taproot เมื่อปี 2021 (Taproot เป็นการอัพเกรดสำคัญของ Bitcoin ที่มุ่งเน้นการปรับปรุงความเป็นส่วนตัว ความปลอดภัย และความยืดหยุ่น) ฟิลด์การพัฒนาได้เป็นไปอย่างไรก็ตาม ทราบดีว่า Bitcoin ขาดความยืดหยุ่นที่เพียงพอที่จะให้บริการอย่างแท้จริงแก่ประชากรมากมายในโลก หรือแม้แต่การให้ความยืดหยุ่นในลักษณะที่เชื่อถือได้หรือในลักษณะการคุมสำรองที่สามารถเรียกใช้ได้มากกว่าสถาบันการคุมสำรองและผู้ให้บริการขนาดใหญ่มากๆ และไม่สามารถหลบหลีกจากข้อจำกัดในการควบคุมของรัฐบาลในทางจริงจัง

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

ตัวอย่างเช่น ANYPREVOUT (APO) เป็นข้อเสนอที่อนุญาตให้นําลายเซ็นกลับมาใช้ใหม่ในธุรกรรมต่างๆ ตราบใดที่สคริปต์อินพุตและจํานวนเงินเหมือนกัน ข้อเสนอนี้ได้รับการออกแบบมาโดยเฉพาะเพื่อเพิ่มประสิทธิภาพเครือข่าย Lightning และเวอร์ชันหลายฝ่าย CHECKTEMPLATEVERIFY (CTV) เป็นข้อเสนอที่ต้องใช้เหรียญโดยธุรกรรมที่ตรงกับธุรกรรมที่กําหนดไว้ล่วงหน้าเท่านั้น ข้อเสนอนี้ออกแบบมาเพื่อขยายการทํางานของห่วงโซ่ธุรกรรมที่ลงนามล่วงหน้าโดยทําให้ไม่น่าเชื่อถืออย่างสมบูรณ์ OP_VAULT ได้รับการออกแบบมาโดยเฉพาะเพื่อตั้งค่า "หมดเวลา" สําหรับโซลูชันห้องเย็นเพื่อให้ผู้ใช้สามารถ "ยกเลิก" การถอนเงินจากห้องเย็นโดยส่งไปยังการตั้งค่าหลายลายเซ็นที่เย็นกว่าเพื่อป้องกันไม่ให้คีย์รั่วไหล

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

นอกเหนือจากผู้เสนอ ไม่มีใครเชื่อว่าข้อเสนอใด ๆ ก็จะครอบคลุมพอที่จะถือเป็นขั้นตอนต่อไปที่เหมาะสม

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

รหัสปฏิบัติ (Operation Codes)

• OP_CAT: รับข้อมูลสองชิ้นจากสแต็กและบวกกันเพื่อสร้างข้อมูลหนึ่งชิ้น
• OP_SUBSTR: ยอมรับพารามิเตอร์ความยาว (ในหน่วยไบต์) ได้รับชิ้นข้อมูลจากสแต็ก ลบบายต์ของความยาวนั้นและนำมันกลับไปบนสแต็ก
• OP_LEFT และ OP_RIGHT: ยอมรับพารามิเตอร์ความยาว นำชิ้นของข้อมูลจากสแต็กและลบไบต์ของความยาวที่ระบุจากด้านหนึ่งหรืออีกด้านหนึ่งของมัน
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT และ OP_DOWNSHIFT: ยอมรับองค์ประกอบข้อมูลและดำเนินการดำเนินการทางบิตที่เกี่ยวข้องกับมัน
• OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, และ OP_MOD: ตัวดำเนินการทางคณิตศาสตร์สำหรับการคูณ, หาร, และการดำเนินการ modulo (คืนเศษของการหาร)

นอกเหนือจาก opcodes ที่ระบุไว้ข้างต้นเพื่อกู้คืนแล้ว Rusty Russell ยังเสนอ opcodes เพิ่มเติมสามตัวที่ออกแบบมาเพื่อลดความซับซ้อนของการรวมกันของ opcodes ที่แตกต่างกัน:

OP_CTV (หรือ TXHASH/รหัสคำสั่งเทียบเท่า): ช่วยให้การบังคับที่ละเอียดของส่วนบางส่วนของธุรกรรมเป็นไปตามเนื้อหาที่กำหนดไว้อย่างแม่นยำ

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

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

ทำไมเราถึงทำเช่นนั้น?

Layer2 networks ถือเป็นส่วนขยายของ Bitcoin base layer และถูก จำกัด ด้วยความสามารถของ base layer ก่อนที่ Lightning Network จะสามารถนำมาใช้ได้ ต้องมี soft forks ที่แยกออกเป็น 3 ส่วน: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV), และ Segregated Witness (SegWit)

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

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

จากมุมมองที่สูงขึ้น นี่คือความสามารถที่เราต้องการ:

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

การส่งข้อมูล: ถ้าเราพัฒนาแนวคิดของ UTXO เดียวกับจำนวนคนมากๆ โดยใครก็สามารถเข้าและออกได้อย่างอิสระ ในกรณีนี้ เราต้องมีวิธีการติดตามว่าใครมีเงินเท่าไหร่ โดยทั่วไปใช้ Merkle trees และรากของพวกเขา เมื่อใครบางคนออกไปเราต้องให้แน่ใจว่า “บันทึก” ใครมีสิทธิที่จะได้รับอะไรเป็นส่วนหนึ่งของการเปลี่ยนแปลง UTXO ของเงินของคนอื่นๆ นี้จริงๆแล้วเป็นการใช้งานที่เฉพาะเจาะจงของการสะท้อนตัวเอง

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

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

เมื่อพูดถึงการตรวจสอบลายเซ็นซึ่งเป็นส่วนที่แพงที่สุดของสคริปต์ Bitcoin เรามีวิธีแก้ปัญหาสําหรับสิ่งนี้ที่เรียกว่างบประมาณ Signature Operation (sigops) การใช้ opcode การตรวจสอบลายเซ็นแต่ละครั้งจะใช้ "งบประมาณ" บางอย่างเช่นจํานวนการดําเนินการลายเซ็นที่อนุญาตต่อบล็อกโดยกําหนดขีด จํากัด อย่างหนักสําหรับค่าใช้จ่ายที่จําเป็นในการตรวจสอบบล็อกสําหรับการทําธุรกรรมกับผู้ใช้ Taproot เปลี่ยนวิธีการทํางานนี้โดยไม่ใช้ขีด จํากัด บล็อกส่วนกลางเดียวอีกต่อไป แต่แต่ละธุรกรรมมีขีด จํากัด sigops (การดําเนินการลายเซ็น) ของตัวเองตามสัดส่วนของขนาดของธุรกรรม สิ่งนี้เท่ากับขีด จํากัด ทั่วโลกเดียวกัน แต่ทําให้ง่ายต่อการเข้าใจจํานวน sigops แต่ละธุรกรรมที่มีอยู่

การเปลี่ยนแปลงใน Taproot เกี่ยวกับขีด จํากัด sigops (การดําเนินการลายเซ็น) สําหรับแต่ละธุรกรรมมีความเป็นไปได้ของวิธีการทั่วไปซึ่งเป็นข้อเสนอแนะที่ Rusty Russell เสนอเกี่ยวกับข้อ จํากัด ของ varops แนวคิดคือการจัดสรรต้นทุนสําหรับ opcode ที่เปิดใช้งานใหม่แต่ละรายการเพื่อพิจารณาสถานการณ์ที่เลวร้ายที่สุดที่ opcode แต่ละตัวสามารถสร้างได้ในแง่ของต้นทุนการคํานวณที่แพงที่สุดระหว่างการตรวจสอบ ดังนั้นแต่ละ opcode จะมีขีด จํากัด "sigops" ของตัวเองจํากัดจํานวนทรัพยากรที่สามารถใช้ในระหว่างการตรวจสอบ นอกจากนี้ยังจะขึ้นอยู่กับขนาดของธุรกรรมใด ๆ ที่ใช้ opcodes เหล่านี้ทําให้สะดวกสําหรับการอนุมานในขณะที่ยังคงสะสมถึงขีด จํากัด ทั่วโลกโดยนัยของแต่ละบล็อก สิ่งนี้จะจัดการกับการโจมตี DOS ครั้ง (ทําให้เครือข่ายล่มโดยการส่งคําขอขยะจํานวนมาก) ซึ่งเป็นเหตุผลที่ Satoshi Nakamoto ปิดการใช้งาน opcodes เหล่านี้ในตอนแรก

แรงผลักดันขับไปข้างหน้า

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

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

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

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

คำบรรยาย:

1. บทความเรื่อง “伟大的脚本恢复：比特币的前进之路” นี้ถูกทวีตมาจาก [ บล็อกยูนิคอร์น]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [SHINOBI] หากคุณมีเหตุเป็นปฏิเสธการนำเผยแพร่ กรุณาติดต่อเกต เรียนทีม ทีมจะดำเนินการเมื่อเร็วที่สุด

2. คำประกาศ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงมุมมองส่วนตัวของผู้เขียนเท่านั้น และไม่ใช่เป็นคำแนะนำในการลงทุนใด ๆ

3. การแปลบทความเป็นภาษาอื่น ๆ ถูกทำโดยทีม Gate Learn นอกจากนี้ หากไม่ได้กล่าวถึง การคัดลอก การแจกจ่าย หรือการลอกเลียนบทความที่ถูกแปล นั้นถูกห้าม