What Is a Smart Contract—and Why Its Rules Cannot Be Changed Retroactively?

Disclaimer: This article is for educational purposes only. It is not financial, legal, or investment advice.

A smart contract is often described as a “digital agreement.” That is a useful analogy, but it is not the full picture. More precisely, a smart contract is a program deployed on a blockchain that stores data and executes predefined instructions.

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

ข้อจำกัดสองประการที่ควรรู้ตั้งแต่ต้น:

คำว่า “Smart” ไม่ได้หมายความว่าโปรแกรมสามารถคิดหรือตัดสินเจตนาได้
คำว่า “สัญญา” ไม่ได้ทำให้โค้ดมีสถานะทางกฎหมายเป็นข้อตกลงโดยอัตโนมัติ

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

ประเด็นสำคัญ

Smart contract คือโค้ดและข้อมูลที่จัดเก็บไว้ ณ ที่อยู่บน blockchain

เครือข่ายเรียกใช้ฟังก์ชันตามกฎที่กำหนดไว้ล่วงหน้า

การดำเนินการที่ยืนยันแล้วไม่สามารถแก้ไขย้อนหลังได้ง่าย ๆ

สัญญาบางรายการออกแบบให้มีพารามิเตอร์ที่ปรับได้หรือตรรกะที่อัปเกรดได้

ผู้ใช้ควรตรวจสอบไม่เพียงที่อยู่สัญญา แต่รวมถึงบทบาท สิทธิ์ และกลไกการอัปเกรด

วิธีง่าย ๆ ในการทำความเข้าใจ smart contract

ลองนึกถึงตู้เก็บของอัตโนมัติ

กฎระบุว่า: “ผู้รับสามารถเปิดตู้ได้หลังจากวันที่กำหนดเท่านั้น”
ผู้ส่งฝากสินทรัพย์
ผู้รับพยายามเปิดก่อนกำหนดและเครื่องปฏิเสธ
เมื่อถึงวันที่กำหนด คำขอเดิมจะสำเร็จหากเงื่อนไขอื่นทั้งหมดครบถ้วน

ความแตกต่างคือ smart contract ไม่ได้ทำงานบนเซิร์ฟเวอร์ของบริษัทเดียว เครือข่ายบล็อกเชนจะประมวลผลคำสั่ง บรรลุผลลัพธ์ร่วมกัน และบันทึกไว้

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

โค้ด สถานะ และธุรกรรม

Smart contract มีสามมิติที่ควรพิจารณา:

Code: its available functions and checks.
State: its current data, such as balances, statuses, and configuration values.
Transaction history: the sequence of operations that changed that state.

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

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

คำว่า “เปลี่ยนย้อนหลังไม่ได้” หมายถึงอะไรจริง ๆ

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

If the code includes a refund, reversal, or compensation function, using it creates a new transaction. The blockchain will show the original action and the later response.

นี่คือเหตุผลที่ประวัติ on-chain รองรับการตรวจสอบอย่างอิสระ ผู้สังเกตการณ์ต่างรายสามารถสอบถามเครือข่ายและตรวจสอบลำดับเหตุการณ์เดียวกันได้

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

หมายความว่าสัญญาจะเปลี่ยนแปลงไม่ได้เลยใช่หรือไม่?

ไม่เสมอไป ตรงนี้เองที่คำว่า “สัญญาที่เปลี่ยนแปลงไม่ได้” มักถูกเข้าใจผิด

1. สัญญาที่อัปเกรดไม่ได้

โค้ดที่ติดตั้งใช้งานจะยังทำงานตามตรรกะเดิม นักพัฒนาสามารถติดตั้งสัญญาใหม่ที่ที่อยู่ใหม่ได้ แต่ที่อยู่เดิมและประวัติยังคงอยู่ ผู้ใช้ต้องตั้งใจย้ายไปยังเวอร์ชันใหม่

2. สัญญาที่มีพารามิเตอร์ปรับเปลี่ยนได้

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

สิ่งนี้ไม่เขียนทับอดีต แต่สามารถเปลี่ยนกฎสำหรับการดำเนินการในอนาคต

3. สถาปัตยกรรมที่อัปเกรดได้

การออกแบบที่พบบ่อยใช้สัญญา proxy ที่อยู่ของ proxy จะคงเดิมขณะส่งต่อการเรียกไปยังสัญญา implementation แยกต่างหาก หากระบบกำกับดูแลสามารถเปลี่ยน implementation นั้นได้ พฤติกรรมในอนาคตของที่อยู่ proxy ก็อาจเปลี่ยนไป

จึงหมายความว่า “ที่อยู่ไม่เปลี่ยน” ไม่ได้แปลว่า “ตรรกะไม่เคยเปลี่ยน” เสมอไป การตรวจสอบอย่างรอบคอบควรถามว่า:

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

ตัวอย่าง: การเปลี่ยนขีดจำกัด

ลองนึกถึงสัญญาที่มีขีดจำกัดรายวัน 1,000 หน่วย

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

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

สิ่งที่บล็อกเชนพิสูจน์ได้และพิสูจน์ไม่ได้

Blockchain สาธารณะช่วยตรวจสอบสิ่งต่อไปนี้ได้:

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

Deployment on a blockchain does not by itself guarantee:

การไม่มีข้อบกพร่องหรือช่องโหว่;
นักพัฒนาที่ซื่อสัตย์;
ความยั่งยืนทางเศรษฐกิจ;
ข้อมูลภายนอกที่ถูกต้อง;
การไม่มีอำนาจของผู้ดูแลระบบ;
การคุ้มครองทางกฎหมาย;
การกู้คืนหลังโอนผิด

ความโปร่งใสหมายถึงสามารถตรวจสอบหลักฐานได้ ไม่ได้หมายความว่าทุกสิ่งที่มองเห็นจะปลอดภัย

รายการตรวจสอบก่อนใช้งานจริง

Verify the address. Obtain it from an official project source and compare it carefully.
Verify the network. The same address format may exist across several EVM networks.
Check source verification. Published source code makes analysis easier, but it is not a security audit.
Look for proxies and upgrades. Identify the implementation and the upgrade authority.
Review administrator powers. Look for owner, admin, pause, upgrade, fee, and access-control functions.
Review token approvals. Before approving, confirm the token, spender, and allowance.
Start small. For a first interaction, consider a small test amount while accounting for fees.

เหตุใดลายเซ็นของผู้ใช้จึงสำคัญ

Smart contract ไม่ได้เข้าถึงกระเป๋าเงินทั้งหมดโดยอัตโนมัติ แต่รับการเรียกเฉพาะและใช้ได้เพียงสิทธิ์ที่ได้รับเท่านั้น

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

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

บทสรุป

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

A confirmed operation cannot be quietly edited after the fact. However, future parameters or logic may be changeable if the architecture was designed that way. The most useful question is therefore not only “Is there a smart contract?” but also: “What does its code allow, and who can influence how it works in the future?”

ประเด็นสำคัญ