เสริมเติมแต่ง เนื้่อหาจาก RightTech ep.4: เรื่อง Bitcoin wallet

เนื่องจากพี่อาร์มแนะนำพวกเรื่องของการเลือกแบบตาม platform หรือ OS ไปแล้ว วันนี้ผมมาเติมให้ในส่วนของการเลือกตามวิธีการเก็บ key ครับผม

1. กระเป๋าประเภทสร้างคู่กุญแจแบบอิสระ

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

กระเป๋าเก็บบิตคอยน์โดยทั่วไปนั้นจะมีทั้ง public key เพื่อใช้ในการสร้าง address และ private key สำหรับสร้างลายเซ็นเพื่ออนุมัติการจ่ายบิตคอยน์ หรืออีกประเภทหนึ่งคือประเภทที่มีเฉพาะ public key ในแอพกระเป๋าเก็บบิตคอยน์ โดยเมื่อต้องการใช้บิตคอยน์จะทำงานคู่กับอุปกรณ์ภายนอก เช่น อุปกรณ์ลงลายมือชื่อฮาร์ดแวร์หรือกระเป๋าเงินอื่นในแผนการลงลายมือชื่อหลายรายการ (hardware wallet หรือพวก multisig)

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

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

2. กระเป๋าเก็บบิตคอยน์ประเภทสร้างกุญแจแบบกำหนดได้ (Deterministic Key)

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

สิ่งนี้สามารถช่วยให้เราสามารถนำค่าหนึ่งค่าแปลงไปเป็นอีกค่า ยิ่งไปกว่านั้น การใช้ฟังก์ชันแฮชเดิมกับอินพุตเดิม (seed) จะสร้างค่าใหม่ได้:

```

# Collect some entropy (randomness)

$ dd if=/dev/random count=1 status=none | sha256sum

f1cc3bc03ef51cb43ee7844460fa5049e779e7425a6349c8e89dfbb0fd97bb73 -

# Set our seed to the random value

$ seed=f1cc3bc03ef51cb43ee7844460fa5049e779e7425a6349c8e89dfbb0fd97bb73

# Deterministically generate derived values

$ for i in {0..2} ; do echo "$seed + $i" | sha256sum ; done

50b18e0bd9508310b8f699bad425efdf67d668cb2462b909fdb6b9bd2437beb3 -

a965dbcd901a9e3d66af11759e64a58d0ed5c6863e901dfda43adcd5f8c744f3 -

19580c97eb9048599f069472744e51ab2213f687d4720b0efc5bb344d624c3aa -

```

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

```

f1cc 3bc0 3ef5 1cb4 3ee7 8444 60fa 5049

e779 e742 5a63 49c8 e89d fbb0 fd97 bb73

```

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

3. การสร้างกุญแจแบบลำดับชั้นและกำหนดค่าได้ (HD Key Generation - BIP32)

วอลเล็ตบิตคอยน์สมัยใหม่ทั้งหมดที่เรารู้จักใช้การสร้างกุญแจแบบลำดับชั้นและกำหนดค่าได้ (HD) เป็นค่าเริ่มต้น มาตรฐานนี้ ซึ่งกำหนดไว้ใน BIP32 ใช้การสร้างกุญแจแบบกำหนดค่าได้และการดึง public child key แบบเลือกได้ ด้วยอัลกอริทึมที่สร้าง tree ของกุญแจ ใน tree นี้ กุญแจใด ๆ สามารถเป็นพ่อแม่ของชุด child key และ child key ใด ๆ ก็สามารถเป็นพ่อแม่ของชุด child key อื่น ไม่มีขีดจำกัดตายตัวในความลึกของ tree โครงสร้าง tree นี้แสดงให้เห็นในวอลเล็ต HD: tree ของกุญแจที่สร้างมาจาก seed เดียว

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

#siamstr #righttech

มาลองรัน Bitcoin node กันเถอะ

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

การรันโหนดต้องดาวน์โหลดและประมวลผลข้อมูลมากกว่า 500 GB ในช่วงเริ่มแรก และประมาณ 400 MB ของธุรกรรม Bitcoin ต่อวัน ตัวเลขเหล่านี้เป็นของปี 2023 และอาจเพิ่มขึ้นในอนาคต หากคุณปิดโหนดหรือหลุดจากอินเทอร์เน็ตเป็นเวลาหลายวัน โหนดของคุณจะต้องดาวน์โหลดข้อมูลที่พลาดไป ตัวอย่างเช่น หากคุณปิด Bitcoin Core เป็นเวลา 10 วัน คุณจะต้องดาวน์โหลดประมาณ 4 GB ในครั้งถัดไปที่คุณเริ่มใช้งาน

ขึ้นอยู่กับการเลือกของคุณว่าจะทำดัชนีธุรกรรมทั้งหมดและเก็บสำเนาบล๊อกเชนแบบเต็ม คุณอาจต้องใช้พื้นที่ดิสก์มาก - อย่างน้อย 1 TB หากคุณวางแผนจะรัน Bitcoin Core เป็นเวลาหลายปี โดยค่าเริ่มต้นโหนดบิตคอยน์ยังส่งธุรกรรมและบล็อกไปยังโหนดอื่น ๆ (เรียกว่า "เพียร์") ซึ่งจะใช้แบนด์วิดท์อัปโหลดอินเทอร์เน็ต หากการเชื่อมต่ออินเทอร์เน็ตของคุณมีขีดจำกัด มีขีดจำกัดการใช้ข้อมูลต่ำ หรือคิดค่าบริการตามข้อมูล (เมตเตอร์) คุณไม่ควรรันโหนดบิตคอยน์บนระบบนั้น หรือรันโดยจำกัดแบนด์วิดท์ (ดู การกำหนดค่าโหนด Bitcoin Core) คุณอาจเชื่อมต่อโหนดของคุณแทนไปยังเครือข่ายทางเลือก เช่น ผู้ให้บริการข้อมูลดาวเทียมฟรีอย่าง Blockstream Satellite

Tip: Bitcoin Core เก็บสำเนาบล๊อกเชนแบบเต็ม (ตามค่าเริ่มต้น ) พร้อมธุรกรรมเกือบทั้งหมดที่เคยได้รับการยืนยันบนเครือข่าย Bitcoin ตั้งแต่เริ่มต้นในปี 2009 ชุดข้อมูลนี้มีขนาดหลายร้อย GB และจะถูกดาวน์โหลดเพิ่มขึ้นทีละน้อยในช่วงหลายชั่วโมงหรือหลายวัน ขึ้นอยู่กับความเร็ว CPU และการเชื่อมต่ออินเทอร์เน็ตของคุณ Bitcoin Core จะไม่สามารถประมวลผลธุรกรรมหรืออัปเดตยอดคงเหลือของบัญชีจนกว่าชุดข้อมูล blockchain จะดาวน์โหลดเสร็จสมบูรณ์ ตรวจสอบให้แน่ใจว่าคุณมีพื้นที่ดิสก์ แบนด์วิดท์ และเวลาเพียงพอในการซิงโครไนซ์เริ่มแรก คุณสามารถกำหนดค่า Bitcoin Core เพื่อลดขนาด blockchain โดยการทิ้งบล็อกเก่า แต่โปรแกรมยังคงดาวน์โหลดชุดข้อมูลทั้งหมด

TIPจากหลาม agian: ซื้อ NVMe SSD 2TB เป็นอย่างต่ำซ่ะ m.2 ได้ยิ่งดีเลยจ้า

แม้ว่าจะมีข้อกำหนดด้านทรัพยากรเหล่านี้ แต่มีผู้คนหลายพันรายที่รันโหนด Bitcoin บางคนรันบนระบบง่าย ๆ อย่าง Raspberry Pi (คอมพิวเตอร์ราคา 35 เหรียญสหรัฐที่มีขนาดเท่ากับกล่องบุหรี่)

ทำไมคุณถึงอยากรันโหนด? นี่คือเหตุผลที่พบบ่อยที่สุด:

- คุณไม่ต้องการพึ่งบุคคลที่สามในการตรวจสอบธุรกรรมที่คุณได้รับ

คุณไม่ต้องการเปิดเผยให้บุคคลที่สามรู้ว่าธุรกรรมใดเป็นของกระเป๋าเงินคุณ

- คุณกำลังพัฒนาซอฟต์แวร์ Bitcoin และต้องการพึ่งโหนด Bitcoin เพื่อเข้าถึงเครือข่ายและ blockchain ผ่าน API

- คุณกำลังสร้างแอปพลิเคชันที่ต้องตรวจสอบธุรกรรมตามกฎฉันทามติของ Bitcoin โดยทั่วไป บริษัทซอฟต์แวร์ Bitcoin มักจะรันโหนดหลายโหนด

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

หากคุณกำลังอ่านหนังสือเล่มนี้และสนใจความปลอดภัยที่เข้มงวด ความเป็นส่วนตัวที่เหนือกว่า หรือการพัฒนาซอฟต์แวร์ Bitcoin คุณควรรันโหนดของตัวเอง

การกำหนดค่าโหนด Bitcoin Core

Bitcoin Core จะค้นหาไฟล์การกำหนดค่าในไดเรกทอรีข้อมูลทุกครั้งที่เริ่มทำงาน ในส่วนนี้เราจะตรวจสอบตัวเลือกการกำหนดค่าต่าง ๆ และตั้งค่าไฟล์การกำหนดค่า

เพื่อค้นหาไฟล์การกำหนดค่า ให้รัน bitcoind -printtoconsole ในเทอร์มินัลของคุณ และดูบรรทัดแรก ๆ:

```

$ bitcoind -printtoconsole

2023-01-28T03:21:42Z Bitcoin Core version v24.0.1

2023-01-28T03:21:42Z Using the 'x86_shani(1way,2way)' SHA256 implementation

2023-01-28T03:21:42Z Using RdSeed as an additional entropy source

2023-01-28T03:21:42Z Using RdRand as an additional entropy source

2023-01-28T03:21:42Z Default data directory /home/harding/.bitcoin

2023-01-28T03:21:42Z Using data directory /home/harding/.bitcoin

2023-01-28T03:21:42Z Config file: /home/harding/.bitcoin/bitcoin.conf

...

[a lot more debug output]

...

```

tatatipจากหลามอีกครั้ง: สังเกตเห็นหรือไม่ว่าในตัวอย่างนี้ Bitcoin Core กำลังชี้ไปที่ไฟล์การกำหนดค่าที่ไดเรกทอรี /home/harding/.bitcoin/bitcoin.conf ซึ่งจะแตกต่างกันไปขึ้นอยู่กับผู้ใช้และระบบปฏิบัติการ

คุณสามารถกด Ctrl-C เพื่อปิดโหนดหลังจากที่ระบุตำแหน่งไฟล์การกำหนดค่า โดยปกติไฟล์การกำหนดค่าจะอยู่ในไดเรกทอรี .bitcoin ภายใต้โฮมไดเรกทอรีของผู้ใช้ เปิดไฟล์ configuration ด้วยโปรแกรมแก้ไขได้ตามที่คุณชอบ

Bitcoin Core มีตัวเลือกการกำหนดค่ามากกว่า 100 ตัวเลือกที่สามารถปรับเปลี่ยนพฤติกรรมของโหนดเครือข่าย การจัดเก็บบล๊อกเชน และแง่มุมอื่น ๆ ของการทำงาน เพื่อดูรายการตัวเลือก ให้รัน bitcoind --help:

```

$ bitcoind --help

Bitcoin Core version v24.0.1

Usage: bitcoind [options] Start Bitcoin Core

Options:

-?

Print this help message and exit

-alertnotify=

Execute command when an alert is raised (%s in cmd is replaced by

message)

...

[many more options]

```

นี่คือตัวเลือกที่บางประการที่คุณสามารถตั้งในไฟล์ configuration หรือเป็นพารามิเตอร์บรรทัดคำสั่งสำหรับ bitcoind:

- alertnotify: เรียกใช้คำสั่งหรือสคริปต์เพื่อส่งการแจ้งเตือนฉุกเฉินไปยังเจ้าของโหนดนี้

- conf: ตำแหน่งทางเลือกสำหรับไฟล์ configuration เมื่อใช้เป็นพารามิเตอร์ cli สำหรับ bitcoind เท่านั้น เนื่องจากไม่สามารถอยู่ในไฟล์ configuration ที่มันอ้างถึงได้

- datadir: เลือกไดเรกทอรีและระบบไฟล์สำหรับจัดเก็บข้อมูลบล๊อกเชนตามค่าเริ่มต้นนี้คือไดเรกทอรีย่อย .bitcoin ในไดเรกทอรีโฮมของคุณ ขึ้นอยู่กับการกำหนดค่า สามารถใช้พื้นที่ตั้งแต่ประมาณ 10 GB ถึงเกือบ 1 TB ณ ขณะนี้ คาดว่าขนาดสูงสุดจะเพิ่มขึ้นหลายร้อย GB ต่อปี

- prune: ลดความต้องการพื้นที่ดิสก์บล๊อกเชนลงเหลือกี่เมกะไบต์โดยการลบบล็อกเก่า ใช้สำหรับโหนดที่มีทรัพยากรจำกัดซึ่งไม่สามารถบรรจุบล๊อกเชนแบบเต็มได้ ส่วนอื่น ๆ ของระบบจะใช้พื้นที่ดิสก์อื่นที่ไม่สามารถตัดทอนได้ ดังนั้นคุณยังคงต้องมีพื้นที่อย่างน้อยตามที่ระบุในตัวเลือก datadir

- txindex: รักษาดัชนีของธุรกรรมทั้งหมด ช่วยให้คุณสามารถดึงธุรกรรมใด ๆ โดยใช้ ID ของมันได้โดยโปรแกรม โดยที่บล็อกที่มีธุรกรรมนั้นยังไม่ถูกตัดทอน

- dbcache: ขนาดของแคช UTXO ค่าเริ่มต้นคือ 450 เมบิไบต์ (MiB) เพิ่มขนาดนี้บนฮาร์ดแวร์ระดับสูงเพื่ออ่านและเขียนจากดิสก์น้อยลง หรือลดขนาดลงบนฮาร์ดแวร์ระดับต่ำเพื่อประหยัดหน่วยความจำโดยยอมให้ใช้ดิสก์บ่อยขึ้น

- blocksonly: ลดการใช้แบนด์วิดท์โดยการรับเฉพาะบล็อกของธุรกรรมที่ได้รับการยืนยันจากเพียร์ แทนที่จะส่งต่อธุรกรรมที่ยังไม่ได้รับการยืนยัน

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

เย่ ทีนี้เราก็มีโหนดแล้ววววว -- ไม่อะยังไม่เริ่มเลย 555555

ข้อความจากหลาม agian: คือถึงผมจะสนับสนุนให้คนรันโหนดก็เถอะ แต่ถ้าจะรันโดยไม่รู้อะไรเลยก็ไม่รันซ่ะอาจจะดีกว่า

อยากแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

#siamstr

ก่อนการมาถึงของบิตคอยน์

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

- ฉันจะเชื่อได้อย่างไรว่าเงินนั้นเป็นของจริงและไม่ใช่ของปลอม?

- ฉันจะเชื่อได้อย่างไรว่าเงินดิจิทัลสามารถใช้ได้เพียงครั้งเดียว (ปัญหาการใช้ซ้ำหรือ "double-spend") ?

- ฉันจะมั่นใจได้อย่างไรว่าไม่มีใครสามารถอ้างสิทธิ์ว่าเงินนี้เป็นของพวกเขาไม่ใช่ของฉัน ?

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

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

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

#siamstr

=-=-=-=-=-=-=-=-=-=-=

พึ่งมาอ่านแล้วงงบริบทอย่างงั้นเหรออ งั้นย้อนไปสิ

nostr:nevent1qvzqqqqqqypzq7gq3eup4hk8vlxgugum2vldevv75t3xp7fgr2gjt6f5yh06eyu4qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg6waehxw309a3x7um5wghxcetrw36hy6tx0yhxuet59uqzp63wa7z6q09r7hrv548kudvqfxfsx95znvq2yzaqf9pmzpf4za90ha4jz9

อยากแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

คิ้กค้ากกกก แน่นอนว่าคำประหลาด ๆ แบบนี้มาพร้อมกับการ "ขายของ"

โดยบทความข้างล่างนี้เกี่ยวกับการขยายตัวของ Nostr และความเป็นไปได้ที่อาจจะเกิดขึ้นในอนาคตของรีเลย์ ไม่ว่าจะเป็น

- ป้องกันสแปม

- การขยายตัวของระบบ

- รวมทั้งปัญหาต่าง ๆ ที่มีในปัจจุบันและแนวทางการแก้ปัญหา

#siamstr

nostr:naddr1qvzqqqr4gupzq7gq3eup4hk8vlxgugum2vldevv75t3xp7fgr2gjt6f5yh06eyu4qyv8wumn8ghj7un9d3shjtnwda6x7umgdyh8w6tw9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqz4zxzdn2x3uxvjz9gajhqttttpgk7u2xdayswtad7l

NIP-104: การส่งข้อความแบบ E2EE โดยใช้โปรโตคอล Message Layer Security (MLS)

โดย NIP นี้ได้นำเสนอ E2EE หรือการส่งข้อความที่มีการเข้ารหัสตั้งแต่ต้นทางไปจนถึงปลายทาง โดยเสนอให้มีการเพิ่มไปทั้งแชทส่วนตัวหรือแชทกลุ่ม โดยการใช้โปรโตคอล Messaging Layer Security (MLS)

เดิมทีการส่งข้อความตรงแบบหนึ่งต่อหนึ่ง (DMs) ใน Nostr เกิดขึ้นผ่านรูปแบบที่กำหนดไว้ใน NIP-04 แต่ NIP นี้ไม่ได้รับการแนะนำ เพราะแม้ว่ามันจะเข้ารหัสเนื้อหาของข้อความแต่ความเป็นส่วนตัวของเราและคู่สนทนานั้นกลับไม่มีอยู่เลย

แต่ด้วยการมาของ NIP-44 ทำให้เรามีรูปแบบการเข้ารหัสที่อัปเดตซึ่งปรับปรุงการรับประกันความลับ แต่ก็ไม่ได้กำหนดรูปแบบใหม่สำหรับการส่งข้อความตรง โดยใช้รูปแบบการเข้ารหัสนี้ ดังนั้น จึงแทบจะไม่สร้างความแตกต่างใด ๆ กับความเป็นส่วนตัว

และล่าสุดนี้ NIP-17 ได้รวมการเข้ารหัส NIP-44 และ warp ด้วย NIP-59 เพื่อซ่อนข้อความตรงที่เข้ารหัสไว้ภายในชุดของกิจกรรมอื่น ๆ เพื่อให้แน่ใจว่าไม่สามารถมองเห็นได้ว่าใครกำลังคุยกับใคร และเมื่อใดที่ข้อความถูกส่งผ่านระหว่างผู้ใช้ ซึ่งส่วนใหญ่จะช่วยแก้ปัญหารั่วไหลของข้อมูล ในขณะที่ยังคงเป็นไปได้ที่จะเห็นว่าผู้ใช้กำลังรับ event ที่ warp แต่คุณไม่สามารถบอกได้ว่ามาจากใคร และ event ประเภทใดที่อยู่ภายใน event ที่ถูก warp ซึ่งจะช่วยให้ปฏิเสธได้ในระดับหนึ่ง แต่ก็ไม่ได้แก้ปัญหาการรักษาความลับล่วงหน้าหรือความปลอดภัยหลังการถูกบุกรุก กล่าวคือ หากกุญแจส่วนตัวของผู้ใช้ (หรือกุญแจการสนทนาที่คำนวณร่วมกันระหว่างผู้ใช้สองคนที่ใช้ในการเข้ารหัสข้อความ) ถูกโจมตี ผู้โจมตีจะสามารถเข้าถึง DMs ทั้งหมดที่ส่งผ่านระหว่างผู้ใช้เหล่านั้นได้อย่างสมบูรณ์ทั้งในอดีตและอนาคต

นอกจากนี้ ทั้ง NIP-04 หรือ NIP-17 ต่างก็ไม่ได้พยายามแก้ปัญหาของการส่งข้อความในแชทกลุ่ม

แล้วทำไมมันถึงสำคัญละ?

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

แล้วทำไมต้องเป็น MLS?

การปรับใช้โปรโตคอล Message Layer Security (MLS) ให้เข้ากับการใช้งาน Nostr ลองคิดง่าย ๆ ว่า MLS เป็นวิวัฒนาการของ Signal Protocol ก็ได้ อย่างไรก็ตาม MLS ได้ปรับปรุงความสามารถในการขยายขนาดของการดำเนินการเข้ารหัสสำหรับการส่งข้อความกลุ่มขนาดใหญ่ได้อย่างมาก (linear -> log) โดยสร้างขึ้นเพื่อรองรับสภาพแวดล้อมแบบรวมศูนย์ และยังช่วยให้อัปเดตชุดรหัสและเวอร์ชันได้อย่างราบรื่นเมื่อเวลาผ่านไป นอกจากนี้ยังมีความยืดหยุ่นสูงและข้อความเข้ารหัสที่ส่งในระบบนั้นไม่ขึ้นอยู่กับเนื้อหาของข้อความที่ส่ง การอธิบายโปรโตคอล MLS นั้นอยู่นอกเหนือขอบเขตของ NIP นี้ แต่คุณสามารถอ่านเพิ่มเติมได้ในภาพรวมทางสถาปัตยกรรมหรือ RFC MLS กำลังอยู่ระหว่างการพัฒนาเป็นมาตรฐานอินเทอร์เน็ตภายใต้ IETF ดังนั้นโปรโตคอลจึงได้รับการตรวจสอบและวิจัยมาเป็นอย่างดี ซึ่งหมายความว่า MLS มีศักยภาพในการทำงานร่วมกันของการส่งข้อความข้ามเครือข่ายได้ในอนาคต เมื่อ MLS ได้รับการยอมรับมากขึ้น

MLS มีจุดเด่นอะไรที่จะมาช่วยพัฒนา Nostr ได้บ้าง?

- ความเป็นส่วนตัวและความปลอดภัย: แม้ว่าระบบการส่งข้อความส่วนตัวบน nostr ที่มีอยู่แล้วและมีความปลอดภัยที่สูง(NIP-04, NIP17) แต่ในแง่ของความเป็นส่วนตัวนั้นยังบกพร่องอยู่ ซึ่งในจุดนี้เองที่ MLS สามารถเข้ามาช่วยเพิ่มความเป็นส่วนตัวได้

- ความหยืดหยุ่น: MLS นั้นมีระบบการจัดการข้อความแบบกลุ่ม ซึ่งสามารถจัดการได้อย่างมีประสิทธิภาพสูง ซึ่งน่าจะเข้ามาช่วยเสริม

- การสอดคล้องกับการกระจายอำนาจ: การใช้ประโยชน์จากโครงสร้างพื้นฐานรีเลย์แบบกระจายอำนาจที่มีอยู่ของ Nostr สำหรับการส่งข้อความ MLS ทำให้สามารถส่งข้อความได้อย่างปลอดภัย และมีความเป็นส่วนตัวมากขึ้น

เป้าหมายของ NIP นี้

- ข้อความตรงและข้อความกลุ่มแบบส่วนตัวและเป็นความลับ

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

- เป็นความลับ หมายความว่าเฉพาะผู้รับที่ต้องการเท่านั้นที่สามารถดูเนื้อหาของการสนทนาได้

- การรักษาความลับล่วงหน้าและความปลอดภัยหลังการถูกบุกรุก

- การรักษาความลับล่วงหน้า หมายความว่าเนื้อหาที่เข้ารหัสในอดีตจะยังคงถูกเข้ารหัสอยู่ แม้ว่ากุญแจจะรั่วไหลก็ตาม

- ความปลอดภัยหลังการถูกบุกรุก หมายความว่าการรั่วไหลของคีย์ไม่อนุญาตให้ผู้โจมตีอ่านข้อความในอนาคตได้อย่างไม่มีกำหนด

- ปรับขนาดได้อย่างมีประสิทธิภาพสำหรับกลุ่มขนาดใหญ่

- อนุญาตให้ใช้อุปกรณ์/ไคลเอนต์หลายเครื่องในการสนทนา/กลุ่มเดียว

Mining & Pool

Mining หรือการขุด เป็นอีกหนึ่งสิ่งที่เป็นพื้นฐานของระบบบิตคอยน์ ซึ่งดำเนินการโดยการนำกำลังประมวลผลมาแข่งกันในการหา hash ให้เข้าเป้า เพื่อที่จะให้ได้รับสิทธิ์ในการใส่บล๊อกที่ตนสร้างลงไปในบล๊อกเชนของบิตคอยน์ และนักขุดที่สามารถหา nonce ที่ทำให้ hash เข้าเป้าได้ก่อนก็จะได้รับบิตคอยน์ที่ถูกผลิตขึ้นใหม่ในบล๊อกนั้น ๆ และ ค่าธรรมเนียมจากการทำธุรกรรมต่าง ๆ ในบล๊อกนั้น ๆ อีกด้วย แต่หลังจากเครือข่ายของบิตคอยน์ได้มีการเจริญเติบโตขึ้นเรื่อย ๆ ทำให้การแข่งขันกันของเหล่านักขุดก็เกิดขึ้นด้วย เมื่องแรงขุดในระบบเพิ่มขึ้น ความยากในการหา hash ที่จะตรงกับเป้าหมายก็ยากขึ้นเรื่อย ๆ ตาม difficulty adjustment algorithm อีกด้วย ด้วยเหตุนี้เองจึงทำให้โอกาสที่นักขุดที่ขุดด้วยตัวคนเดียวจะสามารถได้รับบิตคอยน์จากการขุดนั้นยากขึ้นเรื่อย ๆ เหล่าบรรดานักขุดจึงเริ่มมีการรวมกำลังในการขุดของแต่ละคน เพื่อเพิ่มโอกาสที่จะได้รับบิตคอยน์จากการขุด จึงเกิดเป็นสิ่งที่เรียกว่า Mining Pool ในภายหลัง

Mining Pool คืออะไร?

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

จะเกิดอะไรขึ้นถ้ามี pool ใด ๆ ที่รวมกำลังขุดเกิน 51 % ? จะมีปัญหาอะไรไหม ?

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

#siamstr

OP_CHECKTEMPLATEVERIFY (CTV)

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

เดิมทีนำเสนอภายใต้ชื่อ OP_CHECKOUTPUTSHASHVERIFY (COSHV) ซึ่งข้อเสนอนี้มุ่งเน้นไปที่ความสามารถในการสร้างธุรกรรมโดยใช้ congestion control (คล้าย ๆ กันกับที่ใช้คุมการไหลของ data packets ใน TCP ) ซึ่งผู้ใช้จ่ายเงินไปยังที่อยู่เดียวโดยใช้ CTV ซึ่งเมื่อได้รับการยืนยันในระดับที่เหมาะสมแล้ว จะทำให้ผู้รับหลายรายมั่นใจได้ว่าพวกเขาแต่ละคนจะได้รับเงิน กระบวนการสองขั้นตอนนี้น่าจะสามารถใช้ได้ทุกที่ ที่มีตัวเลือกการรวมการชำระเงิน (payment batching) โดยมีแนวโน้มว่าจะสามารถช่วยลดค่าธรรมเนียมได้มากกว่าการรวมการชำระเงิน

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

การทำงานของ OP_CHECKTEMPLATEVERIFY

OP_CHECKTEMPLATEVERIFY ใช้โอปโค้ด OP_NOP4 (0xb3) เป็นการอัปเกรดซอฟต์ฟอร์ก

OP_CHECKTEMPLATEVERIFY ทำงานดังนี้:

- ต้องมีอย่างน้อยหนึ่งองค์ประกอบบนสแต็ก ไม่งั้นจะไม่สามารถทำงานได้

- องค์ประกอบบนสแต็กต้องมีความยาว 32 ไบต์ หากไม่ใช่จะทำเป็น NOP (No Operation)

- DefaultCheckTemplateVerifyHash ของธุรกรรม ณ ดัชนีอินพุตปัจจุบันต้องเท่ากับองค์ประกอบบนสแต็ก หากไม่เท่ากันจะล้มเหลว

- DefaultCheckTemplateVerifyHash ผูกมัดกับ: เวอร์ชัน,ล็อกไทม์, แฮชของ ScriptSigs (ถ้ามี ScriptSigs ที่ไม่ใช่ค่า Null), จำนวนอินพุต, แฮชของลำดับ, จำนวนเอาต์พุต, แฮชของเอาต์พุต, ดัชนีอินพุตที่กำลังดำเนินการอยู่

กฎมาตรฐานที่แนะนำเพิ่มเติม:

ปฏิเสธข้อมูลที่ไม่ใช่ 32 ไบต์ เป็น SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS

detail มากกว่านี้: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

ฮี่ ๆ ไม่ใช้คำเดิมละเดี๋ยวโดนจับได้อีก แต่วันนี้ผมมีของใหม่มานำเสนอ

nostr:naddr1qvzqqqr4gupzq7gq3eup4hk8vlxgugum2vldevv75t3xp7fgr2gjt6f5yh06eyu4qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qq4dyckvstddd48jd6nd94y74ng89znguzlvy6vcje5

#siamstr

Event

Event คืออะไร?

Event เป็น object เพียงประเภทเดียวที่มีอยู่บน Nostr โดยมีโครงสร้างประมาณนี้

```

{"id":"84d5d3dc9c388a702f39cad6360d41ebb804e809fb822f110ff8a14dfd35fc6c",

"pubkey":"66df60562d939ada8612436489945a4ecf1d62346b3d9478dea8a338f3203c64",

"created_at":1722315959,

"kind":1,

"tags":[["t","siamstr"]],

"content":"ไปสั่งกาแฟเมื่อกี้ พส เจ้าของร้านชมว่าเดี๋ยวนี้คล่องภาษาญี่ปุ่นแล้วนะ ไอเราก็ดีใจ พอเดินกลับถึงที่ทำงานละก็ตระหนักได้ว่า ตะกี้เราสั่ง “ไอซ์โคฮี โอเนไงชิมัส” “เทคเอาส์” “คาโดะเดสส” ไอบ้าไหนญี่ปุ่นก่อนอังกฤษทั้งนั้น 🤣🤣\n\n#siamstr",

"sig":"8f066a0099a5f580b605ebdb220179c4eca298947c38b855a0a8bf2783f28ddb537cb74a7f61d3ce8891189f719870efdf320ea4f895e03cdac44284c450c5c4"}

```

อย่าง Event ข้างต้นนี้มี kind เป็น 1 ซึ่งหมายถึง "ข้อความโน้ต" ซึ่งก็คือข้อความธรรมดา สั้น ๆ คล้ายกับที่ใช้กันใน Twitter เช่น บนฟีด การตอบกลับ และการโควท

ประเภทของ Event (Event Kinds)

หมายเลขของ kind แต่ละตัวมีความหมายแตกต่างกัน ตัวอย่างเช่น 0 หมายถึงอีเวนต์ "ข้อมูลเมตา" ใช้สำหรับให้รายละเอียดเกี่ยวกับผู้ใช้ เช่น ชื่อและรูปโปรไฟล์ รีเลย์ (Relays) สามารถจัดการกับ kind ที่แตกต่างกันได้ เช่น รีเลย์มักจะลบอีเวนต์ kind:0 เวอร์ชันเก่ากว่าออกไป และเก็บไว้เฉพาะเวอร์ชันล่าสุด ในขณะที่โดยทั่วไปจะเก็บอีเวนต์ kind:1 ไว้หลายรายการสำหรับแต่ละคีย์

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

คุณสมบัติอื่น ๆ ของ Event

created_at: เป็น Timestamp ของ UNIX ที่กำหนดโดยผู้สร้างอีเวนต์ โดยปกติจะเป็นเวลาที่สร้าง แม้ว่าจะไม่มีการตรวจสอบ แต่ก็ไม่ใช่ปัญหา

content: ขึ้นอยู่กับความหมายของ kind ในกรณีของ kind:1 จะเป็นเพียงสตริงข้อความธรรมดาที่คนอื่น ๆ อ่านได้

tags: ขึ้นอยู่กับ kind เช่นกัน แต่แท็กทั่วไปบางอย่างที่มักปรากฏในอีเวนต์ kind:1 และ kind อื่นๆ คือ "p" ซึ่งใช้เพื่อกล่าวถึงคีย์สาธารณะ และ "e" ใช้เพื่ออ้างถึงอีเวนต์อื่น

อยากแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

Nostr Implementation Possibilities (NIPs)

NIP คืออะไร?

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

ทำไมมันถึงหน้าสนใจ?

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

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

อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

รีเลย์คืออะไร?

รีเลย์เปรียบเสมือนเซิร์ฟเวอร์ที่อยู่เบื้องหลังของ Nostr และทำหน้าที่รับ event ต่าง ๆ มาจากไคลเอนต์ Nostr และอาจจะจัดเก็บและกระจายข้อความเหล่านั้นไปยังไคลเอนต์อื่น ๆ ที่มีการเชื่อมต่ออยู่

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

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

แล้วจะสามารถหารายการรีเลย์ได้จากไหน?

การที่เราจะหารายการรีเลย์ที่เราควรเชื่อมต่อนั้น ๆ จริงแล้ว ๆ สามารถทำได้หลายวิธี แต่วิธีที่ผมแนะนำที่สุดจะเป็นการใช้ตามคนที่เราติดตามอยู่ เพราะจะเป็นวิธีที่เราสามารถเห็น event ต่าง ๆ ของคนที่เราติดตามได้ง่ายที่สุด และเช่นเดียวกัน เพื่อน ๆ หรือคนที่เราติดตามก็จะสามารถเห็น event ของเราได้เช่นกัน และสำหรับในประเทศไทย เรามีรีเลย์ที่คนไทยส่วนใหญ่นิยมใช้กันอยู่สองอัน นั้นคือ wss://relay.siamstr.com/ และ wss://relay.notoshi.win/ ถ้าหากว่าอยากเห็นคนไทยเยอะ ๆ บนหน้าไทม์ไลน์ ผมแนะนำเป็นอย่างยิ่งว่าควรเพิ่ม รายการรีเลย์เหล่านี้ลงไปในบัชญีหรือไคลเอนต์ต่าง ๆ ที่คุณใช้ด้วย

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

จะเกิดอะไรขึ้นถ้ารีเลย์ทั้งหมดที่ฉันเชื่อมต่ออยู่หยุดให้บริการ?

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

แล้วฉันจะสามารถใช้รีเลย์ส่วนตัวได้อย่างไร?

*อะแฮ่ม ๆ ขอบอกไว้ก่อนว่ามันไม่คุ้มค่ากับความยุ่งยากสำหรับคนโดยทั่ว ๆ ไป ถึงในปัจจุบันจะมีเทคโนโลยีบางตัวที่เข้ามาช่วยให้มันทำได้ง่ายขึ้นแล้วก็ตาม

หากคุณต้องการที่จะสำรองข้อมูลนั้น การที่จะมีรีเลย์ส่วนตัวที่ออนไลน์ตลอดเวลาอาจเป็นเรื่องที่ไม่ได้จำเป็นขนาดนั้น เนื่องจากเราสามารถใช้งานบริการอย่าง https://nostrsync.live/ ในการดาวน์โหลดข้อมูลของเราจากรีเลย์ต่าง ๆ ได้ หรือการติดตั้งรีเลย์ส่วนตัวอย่าง nostr-relay-tray: https://github.com/CodyTseng/nostr-relay-tray ที่ช่วยให้เราสามารถมีรีเลย์ส่วนตัวที่ใช้สำหรับสำรองข้อมูลได้

อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

ไคลเอนต์คืออะไร?

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

เรียบง่ายและยืดหยุ่น?

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

ลงชื่อเข้าใช้ ไคลเอ็นต์หลาย ๆ ตัวแล้วจะกระทบต่อความปลอดภัยของแอคเคาร์ไหม?

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

#siamstr

อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

องค์ประกอบของโปรโตคอลที่ชื่อว่า Nostr

หลังจากได้ทำความรู้จัก Nostr กันไปแล้วเมื่อคราวก่อน คราวนี้เรามาเจาะดูองค์ประกอบของโปรโตคอลนี้กันดีกว่า

Keys ระบบบัญชีผู้ใช้และรหัสผ่านสำหรับ Nostr

บัญชี Nostr แต่ละบัญชีจะใช้คู่กุญแจสาธารณะ/ส่วนตัว (Public/Private Key ) เปรียบเทียบง่าย ๆ คือ กุญแจสาธารณะของคุณคือชื่อผู้ใช้ และกุญแจส่วนตัวก็เป็นรหัสผ่าน แต่ว่า ก็มีข้อแตกต่างที่สำคัญอยู่ นั่นคือ กุญแจส่วนตัวของคุณนั้นจะไม่สามารถรีเซ็ตได้หากเกิดการสูญหายขึ้น คุณจะเสียบัญชีนั้นไปตลอดกาล

โดยทั่วไปแล้ว กุญแจสาธารณะจะแสดงเป็นข้อความที่ขึ้นต้นด้วย npub1 และกุญแจส่วนตัวจะขึ้นต้นด้วย nsec1

ทั้งนี้คุณควรที่จะตรวจสอบให้แน่ใจว่าคุณได้เก็บกุญแจส่วนตัวของคุณไว้ในที่ปลอดภัย เช่น โปรแกรมจัดการรหัสผ่านอย่างเช่น Bitwarden

โปรโตคอลกับไคลเอนต์ ต่างกันอย่างไร?

Nostr เองเป็นเพียงโปรโตคอล หมายความว่า Nostr นั้นเป็นเพียงกระบวนการที่ตกลงกันไว้สำหรับการส่งข้อความผ่านอินเทอร์เน็ต (เหมือนข้อกำหนด)

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

การพิสูจน์ความเป็นเจ้าของข้อมูลบน Nostr

บน Nostr นั้นการพิสูจน์ตัวตนเป็นเรื่องที่ง่ายมากเนื่องจากทุก ๆ event ที่เกิดขึ้น *จำเป็น*ต้องมีลายเซ็นดิจิทัล (Digital Signature) โดยลายเซ็นนั้นจะช่วยให้มั่นใจได้ว่า ใครเป็นผู้สร้าง event นั้น ๆ ขึ้นมา โดยการพิสูจน์ทางคณิตศาสตร์

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

ส่วนในกรณีที่คุณใช้งานผ่านเว็บแอป ผมไม่แนะนำให้ใส่กุญแจส่วนตัวลงไป แต่แนะนำให้ใช้ส่วนขยายของเบราว์เซอร์ ที่ใช้งานฟังก์ชันที่เกี่ยวข้องกับ Nostr ซึ่งอนุญาตให้เว็บไคลเอ็นต์ส่ง event ที่ยังไม่ถูกเซ็นมาให้ส่วนขยายและส่วนขยายจะทำหน้าที่เซ็น สำหรับวิธีนี้ เว็บไคลเอ็นต์ต่าง ๆ ไม่จำเป็นต้องรู้กุญแจส่วนตัวของคุณ แต่คุณก็ยังสามารถลงนามใน event ต่าง ๆ ได้ตามปกติ โดยส่วนขยายที่ได้รับความนิยมก็จะเป็น Flamingo, Alby และ nos2x

#siamstr

อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

Nostr: โปรโตคอลทางเลือกใหม่สำหรับโซเชียลมีเดียที่เป็นอิสระ ปลอดภัย และไร้การควบคุม

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

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

เรียบง่าย

- โปรโตคอลนี้ใช้โครงสร้างข้อมูลแบบ Event Object ที่เรียบง่ายและยืดหยุ่น (ซึ่งส่งเป็น JSON ธรรมดา) และใช้การเข้ารหัส แบบ Elliptic-curve มาตรฐานสำหรับคีย์และลายเซ็น

- ช่องทางการสื่อสารที่รองรับเพียงอย่างเดียวคือการเชื่อมต่อ WebSockets จากไคลเอนต์ไปยังรีเลย์

- การออกแบบนี้ทำให้ง่ายต่อการพัฒนาไม่ว่าจะไคลเอนต์หรือรีเลย์ และยังช่วยส่งเสริมความหลากหลายของซอฟต์แวร์

ยืดหยุ่น

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

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

- รีเลย์จำนวนมากได้ตามต้องการ และยังสามารถเปลี่ยนแปลงได้ตลอดเวลาอีกด้วย

ตรวจสอบได้

- เนื่องจากบัญชี Nostr ใช้การเข้ารหัสแบบ PKE จึงง่ายต่อการตรวจสอบว่าข้อความถูกส่งมาจากผู้ใช้ที่ระบุจริงหรือไม่

เช่นเดียวกับ HTTP หรือ TCP-IP Nostr เป็นโปรโตคอลหรือมาตรฐานแบบเปิดที่ทุกคนสามารถนำไปสร้างต่อยอดได้ มันไม่ใช่แอปหรือบริการที่คุณจำเป็นต้องลงทะเบียน

แล้วทำไมเราถึงต้องการ Nostr?

โซเชียลมีเดียได้พัฒนาเป็นช่องทางสำคัญในการไหลเวียนของข้อมูลทั่วโลก แต่น่าเสียดายที่ระบบโซเชียลมีเดียในปัจจุบันของเรานั้นมีข้อบกพร่องมากมาย:

1. ใช้ความสนใจของคุณเพื่อขายโฆษณา

2. ใช้เทคนิคแปลกๆ เพื่อทำให้คุณเสพติด (อ้างอิงจากข้อ 1)

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

4. ควบคุมอย่างเต็มที่ว่าใครสามารถเข้าร่วมและใครถูกเซ็นเซอร์

5. เต็มไปด้วยสแปมและบอท

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

#siamstr

อะแฮ่ม ๆ รวมโน๊ตทั้งหมดที่เกี่ยวกับ BTC whitepaper มาแล้ว อ่านทีเดียวยาว ๆ ได้เลย เย้

#siamstr

nostr:naddr1qvzqqqr4gupzq7gq3eup4hk8vlxgugum2vldevv75t3xp7fgr2gjt6f5yh06eyu4qyv8wumn8ghj7un9d3shjtnnd9sk6um5wghxxmmd9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqz4ck5cj5fakhxmntvfyk236ht9qkwstzxgeq489nk8

12. Conclusion

เราได้นำเสนอระบบธุรกรรมอิเล็กทรอนิกส์ที่ไม่ต้องพึ่งพาความไว้วางใจ เริ่มต้นจากกรอบแนวคิดของเหรียญที่สร้างจากลายเซ็นดิจิทัล ซึ่งช่วยควบคุมความเป็นเจ้าของได้อย่างดีแต่ก็ยังไม่สมบูรณ์ หากปราศจากวิธีการป้องกันการใช้จ่ายซ้ำซ้อน เพื่อแก้ปัญหานี้ เราจึงเสนอเครือข่ายแบบเพียร์ทูเพียร์ที่ใช้ proof-of-work ในการบันทึกประวัติธุรกรรมสาธารณะ ซึ่งจะกลายเป็นเรื่องยากอย่างมากสำหรับผู้โจมตีที่จะเปลี่ยนแปลง หาก node ที่ซื่อสัตย์ควบคุมพลังประมวลผล CPU ส่วนใหญ่ เครือข่ายนี้มีความแข็งแกร่งในความเรียบง่ายที่ไม่มีโครงสร้างใด ๆ ที่ซับซ้อน node ต่าง ๆ ทำงานพร้อมกันโดยประสานงานกันเพียงเล็กน้อย ไม่จำเป็นต้องระบุตัวตน เนื่องจากข้อความไม่ได้ถูกส่งไปยังสถานที่ใดสถานที่หนึ่งโดยเฉพาะ และเพียงแค่ต้องส่งมอบให้ถึงมือผู้รับอย่างดีที่สุด node สามารถออกจากและเข้าร่วมเครือข่ายได้ตามต้องการ โดยยอมรับ chain ที่มี proof-of-work มากที่สุดเป็นสิ่งที่เกิดขึ้นในขณะที่ไม่ได้เชื่อมต่อ พวกเขาโหวตด้วยพลังประมวลผล CPU แสดงการยอมรับบล็อกที่ถูกต้องโดยการทำงานเพื่อขยายบล็อก และปฏิเสธบล็อกที่ไม่ถูกต้องโดยการปฏิเสธที่จะทำงานกับบล็อกเหล่านั้น กฎและแรงจูงใจใด ๆ ที่จำเป็นสามารถบังคับใช้ได้ด้วยกลไกฉันทามตินี้

#siamstr

11. Calculations

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

การแข่งขันระหว่าง chain สุจริตกับ chain ของผู้โจมตี สามารถอธิบายได้ด้วยแบบจำลองการเดินสุ่มทวินาม (Binomial Random Walk) โดยเหตุการณ์ที่สำเร็จ หมายถึง chain ที่สุจริตถูกขยายออกไปอีกหนึ่งบล็อก เพิ่มความยาวนำหน้าไป +1 และเหตุการณ์ที่ล้มเหลว หมายถึง chain ของผู้โจมตีถูกขยายออกไปหนึ่งบล็อก ลดช่องว่างลง -1

ความน่าจะเป็นที่ผู้โจมตีจะไล่ตามทันจากช่องว่างที่กำหนด สามารถเปรียบเทียบด้วย Gambler's Ruin problem โดยสมมติว่านักพนันที่มีเครดิตไม่จำกัด เริ่มต้นด้วยการขาดทุน และเล่นพนันไปเรื่อย ๆ เพื่อให้ถึงจุดคุ้มทุน เราสามารถคำนวณความน่าจะเป็นที่เขาจะกลับมาถึงจุดคุ้มทุนได้ หรือความน่าจะเป็นที่ผู้โจมตีจะไล่ทัน chain ที่สุจริตได้ ดังนี้ [8]:

p = ความน่าจะเป็นที่ Node ที่สุจริตจะพบบล็อกถัดไป

q = ความน่าจะเป็นที่ผู้โจมตีจะพบบล็อกถัดไป

qz = ความน่าจะเป็นที่ผู้โจมตีจะไล่ทัน จากที่ตามหลังอยู่ z บล็อก

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

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

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

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

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

จัดเรียงใหม่เพื่อหลีกเลี่ยง infinite tail ของการแจกแจง

แปลงมันให้เป็น C code

#include

double AttackerSuccessProbability(double q, int z)

{

double p = 1.0 - q;

double lambda = z * (q / p);

double sum = 1.0;

int i, k;

for (k = 0; k <= z; k++)

{

double poisson = exp(-lambda);

for (i = 1; i <= k; i++)

poisson *= lambda / i;

sum -= poisson * (1 - pow(q / p, z - k));

}

return sum;

}

เมื่อรันผลลัพธ์บางส่วน เราจะเห็นว่าความน่าจะเป็นลดลงแบบเอกซ์โพเนนเชียลเมื่อ z เพิ่มขึ้น

q=0.1

z=0 P=1.0000000

z=1 P=0.2045873

z=2 P=0.0509779

z=3 P=0.0131722

z=4 P=0.0034552

z=5 P=0.0009137

z=6 P=0.0002428

z=7 P=0.0000647

z=8 P=0.0000173

z=9 P=0.0000046

z=10 P=0.0000012

q=0.3

z=0 P=1.0000000

z=5 P=0.1773523

z=10 P=0.0416605

z=15 P=0.0101008

z=20 P=0.0024804

z=25 P=0.0006132

z=30 P=0.0001522

z=35 P=0.0000379

z=40 P=0.0000095

z=45 P=0.0000024

z=50 P=0.0000006

การแก้หาค่า P ที่น้อยกว่า 0.1%...

P < 0.001

q=0.10 z=5

q=0.15 z=8

q=0.20 z=11

q=0.25 z=15

q=0.30 z=24

q=0.35 z=41

q=0.40 z=89

q=0.45 z=340

#siamstr

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

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

9. Combining and Splitting Value

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

ควรสังเกตว่า fan-out (กระจายของธุรกรรม) ซึ่งเป็นกรณีที่ธุรกรรม ธุรกรรมหนึ่งนั้นขึ้นอยู่กับหลายธุรกรรม และธุรกรรมเหล่านั้นเองก็ขึ้นอยู่กับอีกหลายธุรกรรม แต่ไม่ใช่ปัญหาในที่นี้ เพราะไม่มีความจำเป็นในการดึงประวัติการทำธุรกรรมทั้งหมดออกมาเป็นสำเนา

#siamstr

8. การตรวจสอบธุรกรรม (แบบไม่ต้องรัน full node)

การที่จะยืนยันการชำระเงินโดยไม่จำเป็นต้องรัน full node ได้นั้น ผู้ใช้เพียงแค่เก็บสำเนาของส่วนหัวบล็อก (block header) ของสายบล็อก (chain) ที่ยาวที่สุด ซึ่งสามารถรับได้โดยการสอบถามจาก node อื่น ๆ ในเครือข่ายจนมั่นใจว่าได้รับสายที่ยาวที่สุด และรับ Merkle branch ที่เชื่อมโยงธุรกรรมกับบล็อกที่มีการประทับเวลา (Timestamp) อยู่ ถึงแม้ผู้ใช้จะไม่สามารถตรวจสอบธุรกรรมด้วยตัวเองได้ แต่การเชื่อมโยงธุรกรรมกับตำแหน่งในสายบล็อกจะทำให้เห็นว่า node ในเครือข่ายยอมรับแล้ว และบล็อกที่เพิ่มเข้ามาหลังจากนั้นเป็นการยืนยันเพิ่มเติมว่าเครือข่ายยอมรับธุรกรรมนี้แล้ว

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

#siamstr