7. Reclaiming Disk Space
เมื่อธุรกรรมถูกบรรจุลงในบล๊อกแล้ว สามารถกำจัดธุรกรรมที่ใช้ไปแล้วก่อนหน้านั้นออกได้เพื่อประหยัดพื้นที่ดิสก์ แต่การจะทำอย่างนี้ได้โดยไม่ให้เลข hash ของบล๊อกมีการเปลี่ยนแปลงนั้น ธุรกรรมจึงจำเป็นต้องถูก hash ในรูปแบบของ Merkle Tree [7][2][5] โดยมีแค่ root node ของ tree เท่านั้นที่จะรวมอยู่ใน hash ของบล๊อก นี่เป็นวิธีที่ทำให้สามารถบีบอัดข้อมูลในบล๊อกเก่า ๆ ได้โดยการตัดพวก hash ส่วนอื่น ๆ ของ tree ที่ไม่ใช่ root node ออก (ไม่จำเป็นต้องเก็บ hash ในชั้นอื่น ๆ ของ tree)
https://image.nostr.build/3ed95334891d91baca3f3f6f624a7ae22620be4ebfe0db5eb652cfce11255b9a.png
โดยในส่วน header ของบล็อกที่ไม่มีธุรกรรมจะมีขนาดประมาณ 80 ไบต์ หากเราสมมติว่าบล็อกถูกสร้างขึ้นทุก ๆ 10 นาที 80 ไบต์ * 6 * 24 * 365 = 4.2MB ต่อปี โดยที่ระบบคอมพิวเตอร์ทั่วไปที่วางขายในปี 2551 มี RAM 2GB และกฎของมัวร์ทำนายการเติบโตในปัจจุบันที่ 1.2GB ต่อปี การจัดเก็บข้อมูลไม่น่าจะเป็นปัญหาแม้ว่าส่วนหัวของบล็อกจะต้องถูกเก็บไว้ในหน่วยความจำก็ตาม
#siamstr
[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal
trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
[5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference
[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and
Privacy, IEEE Computer Society, pages 122-133, April 1980.
3. Timestamp Server
สำหรับแนวทางการแก้ปัญหาในครั้งนี้ เราจะใช้ประโยชน์จาก timestamp server ที่จะทำหน้าที่บันทึก hash ของบล๊อกที่ต้องการให้มีการบันทึกเวลา และจากนั้นจะทำการเผยแพร่ hash ดังกล่าว เหมือนกับหนังสือพิมพ์หรือโพสต์ใน Usenet [2-5] (ฟีลแบบทุกคนจะเห็นโพสต์นี้น้าา ประมาณนั้น) การบันทึกเวลานี้จะพิสูจน์ได้ว่าข้อมูลที่ถูก hash นั้นจะต้องมีอยู่จริงในเวลานั้นเพื่อให้ได้มาซึ่ง hash ดังกล่าว แต่ละการบันทึกเวลาจะรวมการบันทึกเวลาของหน้านี้ไว้ใน hash ของมันเพื่อสร้างเป็น chain โดยการบันทึกเวลาแต่ละครั้งจะยืนยันความถูกต้องของการบันทึกก่อนหน้าได้อีกด้วยด้วย
https://image.nostr.build/ddf92417c45dbb6e25da0af80a10d4cdbc3e725d047d65f54a3e3bfcf358c4d6.png
[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal
trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
[3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no
2, pages 99-111, 1991.
[4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping,"
In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
[5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference
on Computer and Communications Security, pages 28-35, April 1997.
#siamstr
Oddbean new post about login | logout
Notes by LearnBN | export
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/Emoji บน Nostr บน nostr นั้นการกด reaction (kind 7) ในแต่ละโพสต์นั้นค่อนข้างแตกต่างกับโซเชียลมีเดียอื่น ๆ เป็นอย่างมากเนื่องจากผู้ใช้ทุกคนสามารถที่จะออกแบบและเลือกใช้อิโมจิอะไรก็ได้ที่ตัวผู้ใช้นั้น ๆ ต้องการ โดย emoji จะถูกเก็บอยู่ในลักษณะของ list (NIP-51) เหมือนกับพวก following list, mute list แต่การใช้งานจริง ๆ ทำได้หลากหลายมากกว่านั้น เช่นการจับลง kind 0 หรือ kind 1 ก็สามารถทำได้เช่นกัน ทีนี้เรามาลองดูโครงสร้าง event ของ list emoji กันดีกว่า { "id": "c25122084feb5b70c4c141c515e91dfb6a65c494dae2baf091839ff88a4cc0c3", "pubkey": "66df60562d939ada8612436489945a4ecf1d62346b3d9478dea8a338f3203c64", "created_at": 1710736175, "kind": 30030, "tags": [ [ "d", "ชื่อเซตอิโมจิ"], ["emoji","ชื่อสั้น ๆ ","httpรูปหรือ gif"], [ "emoji","ชื่อสั้น ๆ ""httpรูปหรือ gif"], ["emoji","ชื่อสั้น ๆ ","httpรูปหรือ gif"], [ "emoji","ชื่อสั้น ๆ ""httpรูปหรือ gif"], "content": "", "sig": "c4fb0626619fc0881d859570d0d00d72f7a429aca53a322768a6a0c69ddb00e44a87b65bf75a07eb7647407b78803f76720e22eed0724d554470d30371ab1173" } อย่างที่เห็นว่าจุดแตกต่างของ event ที่ทำให้ client ต่าง ๆ รู้ว่ามันคืออีโมจิคือ tag "d"(identifier) และ "emoji" และต้องมีโครงสร้างดังนี้ ["emoji", <shortcode>, <image-url>] เมื่อทำการเผยแพร่ event ในลักษณะนี้แล้วเราก็จะได้ list ของอิโมจิออกมาแบบนี้ nostr:naddr1qvzqqqr4fcpzqeklvptzmyu6m2rpysmy3x295nk0r43rg6eaj3uda29r8rejq0ryqqzy2629dyep8v76 ส่วนถ้าเราต้องการนำ emoji ที่เราสร้างไปใส่ในหน้าโปรไฟล์หรือเวลาเราโพสต์เราต้องทำอย่างไร ? โปรไฟล์(kind 0) { "kind": 0, "content": "{\"name\":\"Alex Gleason :soapbox:\"}", "tags": [ ["emoji", "soapbox", "http s://gleasonator.com/emoji/Gleasonator/soapbox.png"] ], "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6", "created_at": 1682790000 } ใน part ของโปรไฟล์นั้นเพียงแค่เราเพิ่ม shortcode ลงไปในจุดที่เราต้องการใส่และทำการเพิ่ม emoji ใน tag ก็สามารถใช้ได้แล้ว และในทำนองเดียวกันสำหรับการโพสต์ (kind 1) { "kind": 1, "content": "Hello :gleasonator: 😂 :ablobcatrainbow: :disputed: yolo", "tags": [ ["emoji", "ablobcatrainbow", "https: //gleasonator.com/emoji/blobcat/ablobcatrainbow.png"], ["emoji", "disputed", "https: //gleasonator.com/emoji/Fun/disputed.png"], ["emoji", "gleasonator", "https: //gleasonator.com/emoji/Gleasonator/gleasonator.png"] ], "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6", "created_at": 1682630000 } และประเภทสุดท้ายของการใช้ emoji บน nostr และหน้าจะเป็นประเภทที่หลาย ๆ คนใช้กันมากที่สุดอย่างการกด reaction ด้วย emoji จะมี event หน้าตาประมาณนี้ { "kind": 7, "content": ":soapbox:", "tags": [ ["emoji", "soapbox", "https ://gleasonator.com/emoji/Gleasonator/soapbox.png"] ], ...other fields } ทั้งหมดนี้คือวิธีการใช้อิโมจิต่าง ๆ บน nostr ซึ่งจัดเป็นอีกฟังก์ชั่นที่น่าสนใจมาก ๆ ในการเพิ่มสีสันให้สังคม nostr โดยในปัจจุบันมีหลาย ๆ client ได้รองรับการใช้ custom emoji เหล่านี้แล้วส่วนวิธีการสร้างแบบง่าย ๆ โดยที่ไม่ต้องสนใจสิ่งที่กล่าวมาข้างต้นนั้นสามารถทำได้บน emojito.meme หรือ Nostrudel ได้เลย #siamstrLightning Zaps การ zap บน nostr ก็เป็นอีเว้นประเภทหนึ่ง ๆ โดยการใน zap แต่ละครั้งจะประกอบไปด้วย 2 อีเว้นก็คือ zap request (9734) และ zap receipt (9735) โดย flow ในการทำงานของการ zap มีดังนี้ 1. client จะทำการอ่าน LNurl หรือ LNaddress จาก profile ของคนที่เราจะ zap และทำการส่ง request ไปยัง LNaddr server นั้น ๆ เมื่อ server ตอบกลับมาก็จะเช็คพารามิเตอร์สองตัวนั้นคือ allowsNostr(True or False) และ nostrPubkey(ตรงกับ npub ของโปรไฟล์ที่เราจะ zap มั้ย) ตามลำดับ ถ้าถูกต้องจะทำการการอ่านพารามิเตอร์ callback(ส่งเงินไป address ไหน), minSendable(ยอดขั้นต่ำ), และ maxSendable(ยอดสูงสุด) กระบวนการทั้งหมดของข้อนี้คือ zap request 2. เมื่อเราทำการจ่าย invoice เรียบร้อย จะมีการสร้าง zap receipt และส่งไปยัง relay ต่าง ๆ โดย event ของทั้สองประดภทมีลักษณะดังนี้ zap request (9734) { "kind": 9734, "content": "Zap!", "tags": [ ["relays", "รีเลย์หนึ่ง", "รีเลย์สอง"], ["amount", "จำนวนที่เราอยาก zap"], ["lnurl", "lnurl ของคนรับ"], ["p", "pubkey คนรับในรูป hex"], ["e", "event id ที่เราจะ zap"] ], "pubkey": "pubkeyคนส่ง", "created_at": เวลา, "id": " ID ของอีเว้นนี้", "sig": " Digital sigature ของธุรกรรมนี้" } zap receipt (9735) { "id": "ID ของอีเว้นนี้", "pubkey": "pubkey ของคนส่ง", "created_at": เวลาที่สร้าง, "kind": 9735, "tags": [ ["p", "pubkeyคนส่งในรูป hex"], ["e", "event id ที่มีคนมา zap"], ["bolt11", "Ln invoice"], ["description", " zap request ทั้งอีเว้น"], ["preimage", "preimage ของ invoice"] ], "content": "", "sig": "Digital signatureของคนส่ง" } #siamstrNostr event event บน nostr หรือก็คือ โน๊ตหรือข้อมูลต่าง ๆ ที่เราเห็นกันบน nostr ไม่ว่าจะเป็นข้อมูล profile, เนื้อหาบน note, long-form, หรือแม้แต่การไลฟ์ ล้วนแล้วแต่เป็น event ทั้งหมด โดย event จะมีหน้าตาประมาณนี้ { "id": , "pubkey": , "created_at": , "kind": , "tags": [ [...],[...] ], "content": , "sig": } id ก็คือ event id ที่มักจะโชว์เวลาทำการโควทบางโน๊ตบน nostr คำนวณโดยการ นำข้อมูลส่วนอื่น ๆ ใน event (pubkey,create_at,kid,tg,content) มา Serialize จากนั้น hash ด้วย sha256 pubkey ก็คือ npubของเราแต่จะอยู่ในรูปของ hex create_at ก็คือเวลาที่เราสร้างโน๊ต อยู่ในรูปของ unix timestamp ในวินาที kind ก็คือเลขที่ใช้กำหนดประเภทของ event อยู่ในรูปของ int (0-65,535) tag ก็คือ # ที่เราใส่ในโพสต์ต่าง ๆ content ก็คือเนื้อหาที่อยู่บนโน๊ต sig ก็คือ digital signature ของเรา ใช้เพื่อยืนยันว่า note นี้มาจาก nsec นั้น ๆ ที่เป็นเจ้าของ npub นั้น ๆ จริง ๆ คำนวณด้วยการใช้ ECDSA กับ serialized event data จาก id และ private key ของเรา อย่างที่เห็นว่าทุกส่วนของ event ถูกเก็บในรูปของ text แล้ว เราสามารถเห็นรูปภาพหรือวิดีโอบน nostr ได้อย่างไร ? ที่เราสามารถเห็นรูปภาพหรือวิดีโอบน client ต่าง ๆ ของ nostr ได้เนื่องจากการใช้ URL References ถ้าเอาแบบเข้าใจง่าย ๆ ก็คือสิ่งที่เก็บบน event ของ nostr คือ url ที่ใช้ Markdown-style เพื่อทำ image embedding ขึ้นมา #siamstr