Krutt

Krutt's avatar
Krutt
npub1rlxm...dcru
ขอความช่วยเหลือจาก #Siamstr ครับ . คนหวังแจกมัลแวร์แอบอ้างชื่อ เอารีโปเราไปอัพโหลดใหม่ ซ่อนคอมมิทลึกลับไว้เพียบเลยทั้ง ๆ ที่ในรีโปแสดงแต่ว่าอัพเดท 𝘙𝘌𝘈𝘋𝘔𝘌.𝘮𝘥 . ใครที่มีบัญชี 𝖦𝗂𝗍𝖧𝗎𝖻 ฝากรีพอร์ทยูสเซอร์ 𝗆𝗎𝖻𝖾𝖾𝗇𝗍𝖺𝗋𝗂𝗊 และ 𝗋𝖾𝗉𝗈𝗌𝗂𝗍𝗈𝗋𝗒: 𝗆𝗎𝖻𝖾𝖾𝗇𝗍𝖺𝗋𝗂𝗊/𝗍𝗒𝗅𝗌𝗉.𝗇𝗏𝗂𝗆 ที่แอบอ้างชื่อและคอมมิทฮิสโตรีในการเผยแพร่ 𝗆𝖺𝗅𝗐𝖺𝗋𝖾 ในชื่อผมหน่อยนะครับ (𝖱𝖾𝗅𝖾𝖺𝗌𝖾𝗌 ลิสต์เวอร์ชัน 𝟥.𝟥.𝟫 เป็นซิปไฟล์และทาร์บอลจากวันที่ 𝟣𝟧 เดือนพฤษภาคมทั้ง ๆ ที่ไม่มีประวัติคอมมิทในวันนั้น แล้วก็ปลั๊กอินของนีโอวิมไม่จำเป็นต้องดาวน์โหลดรีลีสด้วย) . 𝖦𝗂𝗍𝖧𝗎𝖻 𝗎𝗌𝖾𝗋 คนไหนมีน้ำใจสามารถช่วยผม Report ท้ังยูสเซอร์และรีโปภายใต้หมวด "𝘼𝙘𝙩𝙞𝙫𝙚 𝙈𝙖𝙡𝙬𝙖𝙧𝙚 𝙤𝙧 𝙀𝙭𝙥𝙡𝙤𝙞𝙩𝙨" ผมขอขอบคุณล่วงหน้าครับ . ⚠️⚠️ คำเตือน ลิงก์ข้างล่างนำไปสู่ยูสเซอร์และรีโปผู้หวังร้าย ⚠️⚠️ ⚠️⚠️ 𝖱𝖾𝗉𝗈𝗋𝗍 𝖠𝖻𝗎𝗌𝖾: https://github.com/mubeentariq ⚠️⚠️ ⚠️⚠️ 𝖱𝖾𝗉𝗈𝗋𝗍 𝖠𝖻𝗎𝗌𝖾: https://github.com/mubeentariq/tylsp.nvim ⚠️⚠️
สป็อตไลท์ให้กับ 𝖵𝖺𝗎𝗅𝗍𝗐𝖺𝗋𝖽𝖾𝗇 นิดนึง โปรเจ็กต์ #RIIR สำหรับเซิรฟเวอร์บริการจัดการรหัสผ่านแบบโอเพนซอร์ส 𝖡𝗂𝗍𝗐𝖺𝗋𝖽𝖾𝗇 ช่วยเก็บข้อมูลสำคัญและพาสเวิร์ดแบบไม่พึ่งพาบริการบุคคลที่สาม พอดีไปเจอทิวทอเรียล (𝗍𝗎𝗍𝗈𝗋𝗂𝖺𝗅) สำหรับการดีพลอยบนออร์เคสเตรชันเซอร์วิสชื่อว่า 𝖭𝖺𝗇𝗈𝖼𝗅 มา น่าสนใจมาก . ที่มา / แรงบันดาลใจ * "🦀 Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs 🦀," * "Deploy Vaultwarden on Nanocl," leone; September 17th, 2025. - image
𝕋𝕃;𝔻ℝ 𝘽𝙞𝙩𝙘𝙤𝙞𝙣 = 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙖𝙗𝙡𝙚 𝙈𝙤𝙣𝙚𝙮 🕊 𝘤𝘙𝘺𝘗𝘵𝘖 = 𝘗𝘳𝘰𝘨𝘳𝘢𝘮𝘮𝘦𝘥 𝘔𝘰𝘯𝘦𝘺 🪢 --- ในสองปีที่ผ่านมา ทีม `Krutt` ได้สำรวจวิธีทำสัญญาอนุพันธ์บนบิทคอยน์สองถึงสามวิธี ไม่ว่าจะเป็นการสร้าง 𝖣𝗂𝗌𝖼𝗋𝖾𝖾𝗍 𝖫𝗈𝗀 𝖢𝗈𝗇𝗍𝗋𝖺𝖼𝗍𝗌 ในรูปแบบ 𝖬𝗎𝗍𝗂𝗇𝗒𝖶𝖺𝗅𝗅𝖾𝗍 หรือ 𝟣𝟢𝟣𝟢𝟣 ที่หยุดทำการพัฒนาไป หรือว่าเป็นการค้ำไลท์นิ่งแชนเน่ล ล็อกสภาพคล่องกับผู้ต้องการ 𝖲𝗍𝖺𝖻𝗂𝗅𝗂𝗍𝗒 ในรูปแบบ 𝖲𝗍𝖺𝖻𝗅𝖾 𝖢𝗁𝖺𝗇𝗇𝖾𝗅𝗌 ของ 𝖳𝗈𝗇 𝖪𝗅𝖺𝗎𝗌 แต่ละวิธีที่สำรวจมีข้อเสียจากแรงดึงดูดรวมศูนย์ที่ทำให้โหนดถูกโจมตีได้ง่าย แม้ว่าเมลลิงลิสต์ของไลท์นิ่งจะมีความแอคทีฟสูงในการไล่ตามและปรับปรุง 𝖢𝖵𝖤𝗌 ก็ตาม แต่พ่อหนุ่ม 𝖱𝗈𝖻 𝖧𝖺𝗆𝗂𝗅𝗍𝗈𝗇 ผู้ก่อตั้งและซีอีโอของ 𝖠𝗇𝖼𝗁𝗈𝗋 𝖶𝖺𝗍𝖼𝗁 บริษัทผสานสัมพันธ์ระหว่าง "โต๊ะ" คุมความเสี่ยงเจ้าดั้งเดิมที่เมืองซิคาโก กับโลกของตรรกะอัจฉริยะสร้างสัญญาค้ำมูลค่าด้วบบิทสคริปท์และมินิสคริปท์ เขียนและเปิดโอเพ่นซอร์สสัญญาตรรกะอัจฉริยะล็อกมูลค่าซาโตชิค้ำในสัญญาอนุพันธ์ฟิวเจอรส์ ที่จะทริกเกอร์ในการแอคติเวทข้อนำเสนอพัฒนาและปรับปรุงบิทคอยน์ 𝖡𝖨𝖯-𝟦𝟦𝟦 แหม แหม แหม ธรรมดาโลกไม่จำ เพราะดันเลือกข้อนำเสนอที่แตกแยกคอมมูบิทคอยน์เป็นสองฝ่ายด้วย ช่างเป็นเรื่องน่าศึกษา เราลองมาทำความเข้าใจกันนะครับ . บริบท: 𝗕𝗜𝗣-𝟰𝟰𝟰 คือฮาร์ดฟอร์กทำให้การใช้ 𝖮𝖯_𝖨𝖥 และ 𝖮𝖯_𝖭𝖮𝖳𝖨𝖥 บนฉันทามติกลายเป็นโมฆะเมื่อมีการเปิดใช้งานบิ๊พนี้ ดักทางผู้ใช้งานอินสคริปชันและออร์ดินัลฝากฝังข้อมูล "ขยะ" บนบล็อกเชนของบิทคอยน์ ให้ทำการไม่สำเร็จอีกต่อไป . ร็อบ แฮมิลตันสร้างสัญญาฟิวเจอร์สบนเชนเมนเน็ตอย่างสมบูรณ์ได้อย่างไร ?? สัญญานี้จะเริ่มต้นด้วยการฝากเงินแบบอะตอมิกเข้าสู่ที่อยู่ของสัญญา คนละ 𝟣 𝖡𝖳𝖢 (เพื่อให้แน่ใจว่าทั้งสองฝ่ายนำเงินจำนวนเท่ากันเข้าที่อยู่สัญญา) สัญญานี้ถูกสร้างขึ้นดังนี้: 𝖳𝖺𝗉𝗋𝗈𝗈𝗍 𝖠𝖽𝖽𝗋𝖾𝗌𝗌 ใช้ 𝖭𝖴𝖬𝖲 𝗉𝗈𝗂𝗇𝗍 ตามที่อธิบายใน 𝖡𝖨𝖯-𝟥𝟦𝟣 เพื่อแสดงให้เห็นได้อย่างชัดเจนว่า 𝗄𝖾𝗒 𝗉𝖺𝗍𝗁 ไม่ได้ถูกใช้งาน เรามีสองฝ่าย คือ "𝖸𝖤𝖲" (𝟦𝟦𝟦 เปิดใช้งาน) และ "𝖭𝖮" (𝟦𝟦𝟦 ไม่เปิดใช้งาน) ซึ่งจะเรียกสั้นๆ ว่า 𝖸𝖤𝖲 และ 𝖭𝖮 . ใบไม้ตรรกะแรก (𝗅𝖾𝖺𝖿): เป็นมัลติซิกแบบ 𝟤 ต่อ 𝟤 ของทั้งสองฝ่าย สิ่งนี้มีไว้เพื่อให้สามารถโอน 𝖴𝖳𝖷𝖮 ให้ตัวเองได้หลังจาก 𝖡𝖨𝖯-𝟦𝟦𝟦 เปิดใช้งาน เนื่องจาก 𝖡𝖨𝖯-𝟦𝟦𝟦 เพิ่งเพิ่มข้อกำหนดว่า 𝖴𝖳𝖷𝖮 ที่สร้างก่อนการเปิดใช้งาน จะไม่ได้รับผลบังคับใช้ของกฎฉันทามติ 𝖡𝖨𝖯-𝟦𝟦𝟦 การโอนให้ตัวเองนี้จะทำให้ข้อยกเว้นนั้นถูกลบ . ใบไม้ตรรกะที่สอง: สามารถใช้จ่ายได้สองวิธี คือ เป็นมัลติซิก 𝟤 ต่อ 𝟤 (𝖸𝖤𝖲 และ 𝖭𝖮) เหมือนใบแรก หรือฝ่าย 𝖭𝖮 เพียงฝ่ายเดียว โดยมีไทม์ล็อกที่น้อยกว่าใบที่สาม สิ่งนี้สำคัญเพราะใช้ 𝖮𝖯_𝖭𝖮𝖳𝖨𝖥 . ใบไม้ตรรกะที่สาม: ฝ่าย 𝖸𝖤𝖲 สามารถใช้จ่ายได้หลังจากไทม์ล็อกที่อยู่หลังใบที่สอง ลำดับของไทม์ล็อกสำคัญมาก ถ้า 𝖡𝖨𝖯-𝟦𝟦𝟦 เปิดใช้งาน เงื่อนไขการใช้จ่ายที่ใช้จ่ายได้ก่อนหน้าคุณจะกลายเป็นโมฆะทางฉันทามติ ดังนั้นไม่สำคัญว่าคุณจะเชื่อว่า 𝟦𝟦𝟦 เปิดใช้งานหรือไม่ . บทสรุปรวมแขนงตรรกะสัญญา: - ถ้า 𝖡𝖨𝖯-𝟦𝟦𝟦 เปิดใช้งาน ฝ่ายที่เชื่อว่าใช่จะสามารถใช้ใบที่สองเพื่อนำ 𝖡𝖳𝖢 𝟤 เหรียญออกมา - ถ้า 𝖡𝖨𝖯-𝟦𝟦𝟦 ไม่เปิดใช้งาน ฝ่ายที่เชื่อว่าไม่ จะใช้ใบที่สามเพื่อนำ 𝖡𝖳𝖢 𝟤 เหรียญออกมา เนื่องจากแต่ละฝ่ายมั่นใจในจุดยืนของตน อัตราแลกเปลี่ยนที่ยุติธรรมคือ 𝟣:𝟣 ซึ่งหมายถึงโอกาส 𝟧𝟢% โดยเหลือเวลา 𝟪𝟧 วันก่อนเปิดใช้งาน สัญญานี้ทำให้คุณได้รับ 𝖠𝖯𝖸 โดยปริยายจากบิทคอยน์ของคุณราว ~𝟰𝟯𝟬% ความเสี่ยงคือความเห็นของคุณเกี่ยวกับการเปิดใช้งาน 𝖡𝖨𝖯-𝟦𝟦𝟦 อาจผิด คุณสามารถปรับจำนวนเงินค้ำประกันของแต่ละฝ่ายเพื่อเปลี่ยนอัตราเดิมพันที่มาจากราคาสัญญาฟิวเจอร์สได้ . """ 𝐼 𝑤𝘢𝑛𝘵 𝘱𝑟𝘰𝑔𝘳𝑎𝘮𝑚𝘢𝑏𝘭𝑒 𝑚𝘰𝑛𝘦𝑦, """ 𝘙𝑜𝘣 𝘏𝑎𝘮𝑖𝘭𝑡𝘰𝑛 . ที่มา / โค้ดตัวอย่าง​ : - - --- image
ธนบัตรชอว์เมี่ยน มันต่างจากสลากตรงไหนหล่ะ ? บิทคอยเน่อร์ทำเป็นไม่ชอบ 𝗍𝗈𝗄𝖾𝗇 แต่ก็เห็นอวย 𝖾𝖼𝖺𝗌𝗁 ขนาดนี้ คือไม่มือถือสากปากถือศีลไปหน่อยเหรอ ?? . . โทเค่นคือสลากที่เสกขึ้นมาแบบสองประเภท ไม่ว่าเป็นกลุ่มสเตเบิ้ลคอยน์หรือผูกกับสินทรัพย์ "𝗋𝖾𝖺𝗅-𝗐𝗈𝗋𝗅𝖽" ที่พึ่งพาการจำนองสินทรัพย์นอกระบบ ที่ผู้ใช้บล็อกเชนตรวจสอบไม่สามารถเข้าถึงได้ และสลากโทเค่นเก้าอี้ดนตรีที่ผูกค่ากับโทเค่นอื่น ๆ แล้วติ๊ต่างแทนที่ 𝗀𝗈𝗏𝖾𝗋𝗇𝖺𝗇𝖼𝖾, 𝗌𝗍𝖺𝗄𝗂𝗇𝗀 ฯลฯ แม้ขาดอิทธิพลการเวนคืนมูลค่าเดิมหลังจากการ 𝗋𝗎𝗀𝗉𝗎𝗅𝗅, 𝖽𝖾𝗉𝖾𝗀 หรือ 𝖾𝗑𝗉𝗅𝗈𝗂𝗍 ที่มักเกิดขึ้นจากการแทรกแซงผ่านออราเคิ่ลหรือการทำธุรกรรมแซนด์วิช . . อีแคชคือสัญญาอัจฉริยะพึ่งพาความสามารถสองอย่างสำคัญของเครือข่ายธุรกรรมกระจายศูนย์บิทคอยน์ นั่นก็คือความเสถียรภาพของยอดบัญชีธุรกรรมเป็นกลางไร้กรรมกลาง 𝖯𝗋𝗈𝗈𝖿 𝗈𝖿 𝖶𝗈𝗋𝗄 และระบบพิสูจน์สินทรัพย์สำรอง (𝖯𝗋𝗈𝗈𝖿 𝗈𝖿 𝖱𝖾𝗌𝖾𝗋𝗏𝖾𝗌) บนเลเยอร์สภาพคล่องของบิทคอยน์ที่ชื่อว่าไลท์นิ่ง ด้วยรากฐานสองอย่างนี้ เราสามารถเห็นความแตกต่างอย่างชัดเจนระหว่างเทคโนโลยีไซเฟอร์พังก์ที่มีชื่อว่า 𝖢𝗁𝖺𝗎𝗆𝗂𝖺𝗇 𝖤𝖼𝖺𝗌𝗁 กับเทคโนโลยีของวงการคริปโต ฯ​ ที่มีชื่อว่า 𝖳𝗈𝗄𝖾𝗇 . . เมื่อมองผ่านๆ ปัญหาหลักสองประการของ 𝖾𝖼𝖺𝗌𝗁 คือความเสี่ยงการถูกโกงแบบรวดเร็วโดยการขโมยเงินของทุกคนไปพร้อมกัน และความเสี่ยงการถูกโกงแบบช้าโดยการเพิ่มปริมาณ 𝖾𝖼𝖺𝗌𝗁 อย่างมาก ดูเหมือนไม่เกี่ยวข้องโดยตรงกัน หากกุญแจสำหรับการเก็บรักษา 𝙗𝙞𝙩𝙘𝙤𝙞𝙣 บนเชนและการดำเนินการ 𝖾𝖼𝖺𝗌𝗁 อยู่ในมือของฝ่ายเดียวกันหรือกลุ่มเดียวกัน ความเสี่ยงจากทั้งสองภัยคุกคามจะเท่ากัน ระหว่าง 𝖼𝖺𝗌𝗁𝗎 กับ 𝖿𝖾𝖽𝗂 สองอิมพลีเม้นท์หลัก ๆ ของผู้ให้บริการประเภทนี้ . . 𝖥𝖾𝖽𝗂𝗆𝗂𝗇𝗍 ลดความเสี่ยงทั้งสองนี้ได้พร้อมกันโดยอิงกับแนวทางแบบสหพันธ์ซึ่งทั้งเงินสำรองบนเชนในรูปแบบ 𝗆𝗎𝗅𝗍𝗂𝗌𝗂𝗀 และการดำเนินการรับจำนองมูลค่าบนเครือข่ายกระจายศูนย์บิทคอยน์เป็น 𝖾𝖼𝖺𝗌𝗁 และเวนคืนทรัพย์สินตามข้อตกลงของสหพันธ์นั้น ๆ . . โปรโตคอล 𝖢𝖺𝗌𝗁𝗎 ในสถานะปัจจุบันยังไม่ใช่แบบสหพันธ์และขึ้นอยู่กับการดำเนินงานของมินต์เดียว ซึ่งทำให้การดำเนินการ 𝖾𝖼𝖺𝗌𝗁 รวดเร็วมาก มีประสิทธิภาพในการทำงาน และง่ายต่อการสร้างแอปพลิเคชันบนมัน นั่นหมายความว่าสามารถนำไปใช้ในแอปพลิเคชันที่มีน้ำหนักเบามาก เช่น เว็บไซต์ง่ายๆ หรือการใช้งานขนาดใหญ่มากที่ต้องการประมวลผลธุรกรรมจำนวนมากต่อวินาที นอกจากนี้ ความจริงที่ว่า 𝖢𝖺𝗌𝗁𝗎 ดำเนินงานเฉพาะบนเครือข่าย 𝖫𝗂𝗀𝗁𝗍𝗇𝗂𝗇𝗀 ทำให้ไม่สามารถจัดสหพันธ์มินต์ได้ เพราะเงินในช่อง 𝖫𝗂𝗀𝗁𝗍𝗇𝗂𝗇𝗀 ปัจจุบันสามารถถือโดยฝ่ายเดียวเท่านั้น . . อย่างไรก็ตาม เราสามารถจินตนาการได้ว่ามินต์จะสามารถเข้าถึงเพียงส่วนน้อยของสินทรัพย์สำรอง ในขณะที่ส่วนใหญ่ของเงินทุนสามารถแลกเปลี่ยนออกจาก 𝖫𝗂𝗀𝗁𝗍𝗇𝗂𝗇𝗀 ไปยังที่อยู่บนเชนได้ (𝗋𝗎𝗀𝗉𝗎𝗅𝗅) มินต์จะต้องเก็บเงินสำรองเพียงสัดส่วนเล็กน้อยใน 𝖫𝗂𝗀𝗁𝗍𝗇𝗂𝗇𝗀 เพื่อให้การชำระเงินเป็นไปอย่างราบรื่น และเก็บส่วนใหญ่ที่เคลื่อนที่ช้าบนเชน สัดส่วนของเงินสำรองนี้จำเป็นต้องถูกกำหนดตามความต้องการสภาพคล่องของมินต์เพื่อให้รองรับการถอนเงินของผู้ใช้ในชีวิตประจำวัน . . นอกจากความสามารถ Proof of Reserves บนไลท์นิ่ง ยังมีไซเฟอร์พังก์อีกหลายคนที่กำลังต่อเติมเสริมโปรโตคอล 𝖾𝖼𝖺𝗌𝗁 ด้วยการพิสูจน์หนี้สิน (𝖯𝗋𝗈𝗈𝖿 𝗈𝖿 𝖫𝗂𝖺𝖻𝗂𝗅𝗂𝗍𝗂𝖾𝗌) ของแต่ละมินต์หรือสหพันธ์มินต์อีกด้วย หนึ่งในการนำเสนอวิธีการสร้าง 𝖯𝗈𝖫 อย่างถูกต้องมีความละเอียดอ่อนหลายอย่างที่ปกป้องผู้ใช้งานเซอร์วิส ไม่ให้ถูกหลอกได้มีหลายวิธี ไม่ว่าเป็นการทำตามข้อเสนอ Zero-Knowledge Proof ตามการวิจัยของมูลนิธิสตาร์กแวร์ หรือการสร้าง 𝗋𝖯𝗈𝖫 ตามข้อนำเสนอของ 𝖼𝖺𝗅𝗅𝖾 โดยพึ่งพาการใช้สองขั้นตอนต่อไปนี้ 1. การหมุนเปลี่ยนกุญแจดิจิทัลของผู้ให้บริการมินต์ตามระยะกำหนด โดยผู้ใช้บริการสามารถคัดค้านจำนวนมินต์และเบิร์นถูกต้องได้ด้วย 𝖣𝗂𝗌𝖼𝗋𝖾𝗍𝖾-𝗅𝗈𝗀 𝖾𝗊𝗎𝖺𝗅𝗂𝗍𝗒 พรูฟ (𝖣𝖫𝖤𝖰) 2. การย่อขนาดของบทพิสูจน์พรูฟด้วยตรรกะกิ่งก้านเมอร์เคิ่ล (𝖬𝖾𝗋𝗄𝗅𝖾 𝗉𝗋𝗈𝗈𝖿𝗌) . . โครงสร้าง 𝖯𝗈𝖫 ที่นำเสนอขึ้นอยู่กับความสามารถของผู้ใช้ในการดาวน์โหลดรายงาน 𝖯𝗈𝖫 เพื่อตรวจสอบว่าหลักฐานการสร้างเงิน (𝗆𝗂𝗇𝗍 𝗉𝗋𝗈𝗈𝖿𝗌) และหลักฐานการเผาเงิน (𝖻𝗎𝗋𝗇 𝗉𝗋𝗈𝗈𝖿𝗌) ของตนได้ถูกรวมอยู่ในรายงานหรือไม่ ขึ้นอยู่กับปริมาณการสร้างเงิน 𝖾𝖼𝖺𝗌𝗁 และความถี่ในการปล่อยรายงาน อาจกลายเป็นภาระในแง่ของการใช้ทราฟฟิกอินเทอร์เน็ตและทรัพยากรทางเทคนิคอื่น ๆ สำหรับผู้ใช้ปลายทางบางราย คู่ของหลักฐานสร้างเงินและหลักฐานเผาเงินมีขนาดโดยประมาณประมาณ 𝟣𝟢𝟢 ไบต์ ซึ่งหมายความว่ารายงานขนาด 𝟣 เมกะไบต์ สามารถครอบคลุมธุรกรรม 𝖾𝖼𝖺𝗌𝗁 ได้ประมาณ 𝟣𝟢,𝟢𝟢𝟢 รายการ ตามที่กล่าวไว้ในตอนต้นของเอกสาร ฉบับรายงานควรถูกเผยแพร่บ่อยครั้งเพียงใด และในรูปแบบใดควรถูกเข้ารหัสนั้นจะไม่ถูกขยายความเพิ่มเติมที่นี่ อย่างไรก็ตาม เนื่องจากลำดับเฉพาะของรายการไม่มีผลต่อโครงการ 𝖯𝗈𝖫 จึงอาจมีการทำรายงานให้กลายเป็นเมอร์เคิลต้นไม้ (𝗆𝖾𝗋𝗄𝖾𝗅𝗂𝗓𝖾) และใช้รูปแบบหลักฐานแบบเมอร์เคิล (𝖬𝖾𝗋𝗄𝗅𝖾 𝗉𝗋𝗈𝗈𝖿𝗌) เพื่อให้กระเป๋าเงินสามารถตรวจสอบสถานะหนี้สินของการสร้างเงินได้อย่างมีประสิทธิภาพยิ่งขึ้น . . ที่มา​ / แรงบันดาลใจ : - A Proof of Liabilities Scheme for Ecash Mints - https://gist.github.com/.../ed5228d1d8cbaade0104db5d1cf63939 #BitcoinThai #Siamstr #Siamdev image
𝑆𝑎𝑙𝑡 𝑎𝑛𝑑 𝐿𝑖𝑔ℎ𝑡; วันนี้เป็นวันที่เริ่มเขียนสารสาส์นกะทัดรัด #กูรู้กาเซ็ตต์ เผื่อทุกคนสนใจถึงอนาคตเกินสลากกินไม่แบ่งของโลกเว็บสาม ในเมื่อแรงโน้มถ่วงของบิทคอยน์ตอนนี้ดึงดูดเด็ฟที่ถูกเอาเปรียบจากหลาย ๆ มูลนิธิ ให้กลับมาสนใจไซเฟอร์พังก์เทคกันแล้ว ใครไม่เข้ามาอ่านก็ตกแรงค์กันไป เดลูลู . . 🌐: 🐙: #BitcoinThai #Liquid #Siamdev #Siamstr image
𝙧𝘽𝙋𝙁 ใช่สมาร์ทคอนแทร็กท์เขียนด้วยภาษา #Rust รึเปล่า ? ทำไมถึงต้องมาคู่กับ 𝙗𝙧𝙞𝙗𝙚𝙨 ? . . เป็นหัวข้อหนึ่งที่ไม่อยากพูดถึงในตอนแรก เพราะเมื่อหลายปีที่แล้วเคยกล่าวชมวิธีการรื้อฟื้น 𝘉𝘦𝘳𝘬𝘦𝘭𝘦𝘺 𝘗𝘢𝘤𝘬𝘦𝘵 𝘍𝘪𝘭𝘵𝘦𝘳 จากปีคศ. 𝟙𝟡𝟡𝟚 ในรูปแบบ 𝘦𝘹𝘵𝘦𝘯𝘥𝘦𝘥 เรียกว่า 𝘦𝘉𝘗𝘍 ให้สาวกคริปโต​​​​ ฯ ท่านหนึ่งฟัง แล้วเขาเข้าใจผิดว่าเราลำเอียงเข้าข้างเหรียญที่ใช้ 𝘳𝘶𝘯𝘵𝘪𝘮𝘦 𝘉𝘗𝘍 ตัวหนึ่งไปแล้ว แต่ขออธิบายอย่างแรกก่อนนะครับว่าโปรแกรมที่ดัดแปลงใช้เบิร์กลี่ย์แพคเก็ตฟิลเตอร์ หาใช่สัญญาอัจฉริยะ ที่ปราศจากการแทรกแซงตรรกะแต่อย่างใดนะครับ ถ้าได้อ่านในพาดหัวก็คงจะเห็นคำว่า 𝙗𝙧𝙞𝙗𝙚𝙨 ที่แปลว่าสินบนสำหรับการแทรกแซงนำหน้า ที่เป็นเรื่องสามัญของวงการนี้ไปแล้ว เรามาทำความเข้าใจเทคโนโลยีกันก่อน แล้วชี้ให้เห็นข้อแตกต่างสำคัญกับนิยามของ 𝘚𝘮𝘢𝘳𝘵 𝘊𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴 ที่ประกาศตัวในปีเดียวกันโดยนักพัฒนาไซเฟอร์พังก์ชื่อว่า 𝘕𝘪𝘤𝘬 𝘚𝘻𝘢𝘣𝘰 . . 𝘦𝘉𝘗𝘍 และเทคในแขนง เป็นเวอร์ช่วลแมชชีนที่ใช้รีจิสตรี้ขึ้นตรงกับเคอร์เน่ลของ 𝘓𝘪𝘯𝘶𝘹 โดยตรง มีหน้าที่อ่านแปลความหมาย (𝘐𝘯𝘵𝘦𝘳𝘱𝘳𝘦𝘵𝘪𝘰𝘯) และคอมไพล์แบบจัสท์อินไทม์ (𝘑𝘐𝘛 𝘤𝘰𝘮𝘱𝘪𝘭𝘢𝘵𝘪𝘰𝘯) เปรียบเหมือนรันไทม์ของไพธ่อนและโหนด เว้นแต่เป็นการรันโปรแกรมของยูสเซ่อร์แบบเข้าถึงขั้นเคอร์เน่ลได้ และรับการใช้งานรอบด้านได้แบบกระจายศูนย์ระดับเล็ก (ขึ้นอยู่กับ 𝘉𝘺𝘻𝘢𝘯𝘵𝘪𝘯𝘦 𝘍𝘢𝘶𝘭𝘵 𝘛𝘰𝘭𝘦𝘳𝘢𝘯𝘤𝘦 อัลกอริธึมของเครือข่ายนั้น ๆ) นอกจากนี้ยังห้ามวงจรลูปที่ไม่มีขอบเขต (𝘶𝘯𝘣𝘰𝘶𝘯𝘥𝘦𝘥 𝘭𝘰𝘰𝘱𝘴) ได้โดยการสร้างกราฟการควบคุมการไหล (𝘊𝘰𝘯𝘵𝘳𝘰𝘭-𝘍𝘭𝘰𝘸 𝘎𝘳𝘢𝘱𝘩) และปฏิเสธโปรแกรมที่มีวงจรในนั้น เพื่อให้ผ่านการตรวจสอบนี้ หากมีลูปจะต้องคลี่ลูปออกหรือใช้ฟังก์ชันช่วยที่กำหนด . . ข้อเสียของการทำงานกระจายศูนย์อย่างไม่พึ่งพาสัญญาอัจฉริยะ คือการเติบโตของ 𝘔𝘌𝘝 มูลค่าไหลขึ้น, การใช้งาน 𝘚𝘯𝘪𝘱𝘦𝘳𝘉𝘰𝘵 แทรกแซงการทำงานทางการค้าในรูปแบบแซนด์วิช (𝘴𝘢𝘯𝘥𝘸𝘪𝘤𝘩 𝘢𝘵𝘵𝘢𝘤𝘬𝘴), การสะสมข้อมูลเมต้าดาต้าของผู้ใช้งานเพราะไม่มีการ 𝘢𝘯𝘰𝘯𝘺𝘮𝘪𝘻𝘦 𝘪𝘯𝘴𝘵𝘳𝘶𝘤𝘵𝘪𝘰𝘯 𝘴𝘦𝘵𝘴, การตรวจเช็คแทรกแซงในทุกการใช้งานไม่งั้นมูลค่าสูญหาย, การโจมตีออราเคิ่ล (𝘰𝘳𝘢𝘤𝘭𝘦 𝘢𝘵𝘵𝘢𝘤𝘬𝘴) เพื่อให้แหล่งที่มาข้อมูลคลาดเคลื่อน เพราะผู้สอดส่องสามารถแทรกแซงตรรกะทัวลิ่งได้ ไม่เหมือนตรรกะสัญญาอัจฉริยะ ฯลฯ [จากลิงก์ที่แนบข้อสอง] หรือแม้กระทั่งการทำงานของการโอนมูลค่าแลมพอร์ทก็สามารถทำให้บัญชีไม่ผ่านการประมวล 𝘳𝘦𝘯𝘵-𝘦𝘹𝘦𝘮𝘱𝘵𝘪𝘰𝘯 และโดนระงับได้ เพราะ 𝘈𝘤𝘤𝘰𝘶𝘯𝘵 𝘚𝘺𝘴𝘵𝘦𝘮 แบบมีการแฝง 𝘸𝘳𝘪𝘵𝘦-𝘥𝘦𝘮𝘰𝘵𝘪𝘰𝘯 อยู่หลายโปรแกรม (โปรแกรมนะครับ ไม่ใช่สมาร์ทคอนแทร็กท์) รวมไปถึง 𝚜𝚎𝚌𝚙𝟸𝟻𝟼𝚛𝟷_𝚙𝚛𝚘𝚐𝚛𝚊𝚖 ที่ใช้กันแพร่หลายบนเมนเน็ตของระบบนิเวศน์ตัวหนึ่ง [จากลิงก์ที่แนบข้อสาม] . . กลับมาเล่าเรื่อง 𝙗𝙧𝙞𝙗𝙚𝙨 กันบ้าง เพราะในระบบนิเวศน์ที่ดัดแปลงใข้งาน 𝘦𝘉𝘗𝘍 นั้น ไม่ได้เรียกสิ่งนี้ว่าบั๊กแต่เป็นฟีเจอร์นะครับ หมายถึงแรงจูงใจทางเศรษฐกิจที่ผู้ใช้หรือผู้ค้าจ่ายให้กับผู้ตรวจสอบ (𝘷𝘢𝘭𝘪𝘥𝘢𝘵𝘰𝘳𝘴) เพื่อให้ผู้ตรวจสอบเหล่านั้นจัดลำดับความสำคัญในการประมวลผลธุรกรรมของตนก่อน โดยทั่วไปสินบนนี้มาในรูปแบบของค่าธรรมเนียมลำดับความสำคัญ (𝘱𝘳𝘪𝘰𝘳𝘪𝘵𝘺 𝘧𝘦𝘦𝘴) ซึ่งเป็นค่าธรรมเนียมพิเศษที่ผู้ใช้สามารถตั้งขึ้นเพื่อจูงใจให้ธุรกรรมของพวกเขาถูกใส่ในบล็อกโดยเร็วกว่าธุรกรรมทั่วไป ค่าธรรมเนียมเหล่านี้ถูกคำนวณตามจำนวนหน่วยคอมพิวต์ที่ธุรกรรมใช้และราคาต่อหน่วยคอมพิวต์ที่ผู้ใช้พร้อมจ่าย แปลว่าเป็นระบบลำเอียงอย่างชัดเจน สร้างแรงต่อต้านการกระจายศูนย์เพื่อความเป็นกลาง (𝘯𝘦𝘶𝘵𝘳𝘢𝘭𝘪𝘵𝘺) อย่างมากมาย เพราะการเพิ่มเติมจำนวนผู้ถือหุ้นส่วนย่อมละลายค่าของผู้มาก่อนกาล . . ทางลัดของการสร้างระบบกระจายศูนย์แบบไม่เป็นกลาง จึงหันมาใช้ระบบ 𝘦𝘉𝘗𝘍 แบบดัดแปลงภาษา #รัสท์ และอื่น ๆ นอกจากการใช้งานรัสท์สร้าง 𝘪𝘯𝘵𝘦𝘳𝘱𝘳𝘦𝘵𝘦𝘥 𝘴𝘰𝘧𝘵𝘸𝘢𝘳𝘦 สำหรับ 𝘦𝘉𝘗𝘍 แล้ว ในโลกของไซเฟอร์พังก์ยังมีการนิยมสร้าง 𝘞𝘦𝘣𝘈𝘴𝘴𝘦𝘮𝘣𝘭𝘺 ขนาดกะทัดรัดแพร่หลายกลไกไขรหัสได้อีกด้วยนะครับ ใครที่สนใจการใช้งาน 𝘚𝘪𝘮𝘱𝘭𝘪𝘤𝘪𝘵𝘺 ซึ่งเป็น 𝘙𝘶𝘴𝘵-𝘣𝘢𝘴𝘦𝘥 𝘉𝘭𝘰𝘤𝘬𝘤𝘩𝘢𝘪𝘯 𝘗𝘳𝘰𝘨𝘳𝘢𝘮𝘮𝘪𝘯𝘨 𝘓𝘢𝘯𝘨𝘶𝘢𝘨𝘦 สำหรับสร้าง 𝘚𝘮𝘢𝘳𝘵 𝘊𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘴 สามารถอ่านเพิ่มเติมได้จาก npub นี้นะครับ . . ที่มา / แรงบันดาลใจ 1. In Rust We Trust - Berkeley Packet Filter and Rust, Anatoly Yakovenko - youtu.be/oBW2KJq3FnA 2. arxiv.org/html/2504.07419v1 3. Why Wasm came to Web3, Jakob Meier, 2024. - www.jakobmeier.ch/wasm-road-3 4. The hidden dangers of lamport transfers, Nicola Vella, 2025. - osec.io/blog/2025-05-14-king-of-the-sol #RustProgrammersInThailand #RustThai #SimplicityLang #eBPF #rBPF image