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 View Article →
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 บล็อก image จากสมมติฐานที่ว่า p > q ความน่าจะเป็นจะลดลงแบบเอกซ์โพเนนเชียล เมื่อจำนวนบล็อกที่ผู้โจมตีต้องไล่ตามทันเพิ่มขึ้น หากเขาไม่สามารถพุ่งขึ้นนำได้อย่างรวดเร็วตั้งแต่แรก โอกาสของเขาก็จะลดลงจนน้อยมาก ๆ เมื่อเขาตามหลังมากขึ้นเรื่อย ๆ ทีนี้ลองพิจารณาว่า ผู้รับธุรกรรมใหม่ต้องรอเป็นเวลานานเท่าใด จึงจะแน่ใจได้ว่าผู้ส่งไม่สามารถเปลี่ยนแปลงธุรกรรมได้แล้ว เราสมมติว่าผู้ส่งเป็นผู้โจมตี ที่ต้องการให้ผู้รับเชื่อว่าเขาได้รับเงินไปแล้ว จากนั้นจึงเปลี่ยนให้เงินกลับเข้าหาตัวเองหลังจากเวลาผ่านไประยะหนึ่ง ผู้รับจะได้รับแจ้งเมื่อเกิดเหตุการณ์นี้ขึ้น แต่ผู้ส่งหวังว่ามันจะสายเกินไปแล้ว ผู้รับจะสร้างคู่กุญแจใหม่ และให้กุญแจสาธารณะแก่ผู้ส่งไม่นานก่อนที่จะลงนาม ซึ่งจะป้องกันไม่ให้ผู้ส่งเตรียมบล็อกเชนปลอมไว้ล่วงหน้า โดยการทำงานอย่างต่อเนื่องจนกว่าเขาจะมีโอกาสได้บล็อกที่ยาวพอ จากนั้นจึงดำเนินธุรกรรมในทันที เมื่อส่งธุรกรรมแล้ว ผู้ส่งที่ไม่สุจริตจะเริ่มทำงานอย่างลับ ๆ บนบล็อกเชนคู่ขนาน ที่มีธุรกรรมในเวอร์ชันของเขาเองอยู่ ผู้รับจะรอจนกว่าธุรกรรมจะถูกเพิ่มลงในบล็อก และมีบล็อกที่ถูกเชื่อมต่อตามหลังมาอีก z บล็อก เขาไม่ทราบจำนวนความคืบหน้าที่แน่นอนที่ผู้โจมตีได้ทำไปแล้ว แต่สมมติว่าบล็อกที่สุจริตใช้เวลาเฉลี่ยต่อบล็อกตามที่คาดไว้ ความคืบหน้าที่อาจเกิดขึ้นได้ของผู้โจมตีจะเป็นการแจกแจงแบบปัวซง (Poisson distribution) ซึ่งมีค่าคาดหวังดังนี้: image เพื่อให้ได้ความน่าจะเป็นที่ผู้โจมตียังคงสามารถไล่ทันได้ เราจะคูณความหนาแน่นของปัวซง สำหรับความคืบหน้าแต่ละระดับที่เขาสามารถทำได้ ด้วยความน่าจะเป็นที่เขาสามารถไล่ทันจากจุดนั้น: image จัดเรียงใหม่เพื่อหลีกเลี่ยง infinite tail ของการแจกแจง image แปลงมันให้เป็น C code #include <math.h> 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 คนทั่วไปสามารถเห็นว่ามีคนกำลังส่งเงินจำนวนหนึ่งให้กับคนอื่น แต่จะไม่ทราบข้อมูลที่เชื่อมโยงธุรกรรมนั้นกับบุคคลใด ๆ ซึ่งคล้ายกับระดับข้อมูลที่เปิดเผยโดยตลาดหลักทรัพย์ ซึ่งมีการเปิดเผยเวลาและขนาดของการซื้อขายแต่ละครั้งต่อสาธารณะ แต่ไม่ได้ระบุว่าคู่สัญญาคือใคร image เพื่อเสริมในเรื่องของความปลอดภัย ควรใช้ key pair ใหม่สำหรับการทำธุรกรรมในแต่ละครั้ง เพื่อป้องกันไม่ให้เชื่อมโยงกับเจ้าของคนเดียวกันได้ อย่างไรก็ตาม การเชื่อมโยงบางอย่างยังคงหลีกเลี่ยงไม่ได้ ในธุรกรรมที่มี input หลายรายการ ซึ่งจำเป็นต้องเปิดเผยว่า input เหล่านั้นเป็นของเจ้าของคนเดียวกัน ความเสี่ยงก็คือ หากมีการเปิดเผยตัวตนของเจ้าของคีย์ การเชื่อมโยงอาจเปิดเผยธุรกรรมอื่น ๆ ที่เป็นของเจ้าของรายเดียวกันได้
9. Combining and Splitting Value แม้ว่าการจัดการเหรียญหลาย ๆ เหรียญจะเป็นสิ่งที่สามารถทำได้ แต่การจัดการธุรกรรมแยกต่างหากสำหรับแต่ละเหรียญในการโอนก็คงเป็นเรื่องที่น่าปวดหัวอยู่ดี ฉะนั้นแล้วเพื่อให้สามารถแยกและรวมมูลค่ากันได้ ธุรกรรมจึงสามารถมี input และ output ได้หลายรายการ ซึ่งโดยปกติแล้วจะมี input เดียวจากธุรกรรมก่อนหน้าที่มีขนาดใหญ่กว่า หรือ input จำนวนเล็ก ๆ หลาย ๆ รายการ และ output ไม่เกินสองรายการ คือ รายการหนึ่งสำหรับการชำระเงิน และอีกหนึ่งรายการสำหรับการส่งเงินทอน หากมีกลับไปยังผู้ส่ง image ควรสังเกตว่า fan-out (กระจายของธุรกรรม) ซึ่งเป็นกรณีที่ธุรกรรม ธุรกรรมหนึ่งนั้นขึ้นอยู่กับหลายธุรกรรม และธุรกรรมเหล่านั้นเองก็ขึ้นอยู่กับอีกหลายธุรกรรม แต่ไม่ใช่ปัญหาในที่นี้ เพราะไม่มีความจำเป็นในการดึงประวัติการทำธุรกรรมทั้งหมดออกมาเป็นสำเนา #siamstr
8. การตรวจสอบธุรกรรม (แบบไม่ต้องรัน full node) การที่จะยืนยันการชำระเงินโดยไม่จำเป็นต้องรัน full node ได้นั้น ผู้ใช้เพียงแค่เก็บสำเนาของส่วนหัวบล็อก (block header) ของสายบล็อก (chain) ที่ยาวที่สุด ซึ่งสามารถรับได้โดยการสอบถามจาก node อื่น ๆ ในเครือข่ายจนมั่นใจว่าได้รับสายที่ยาวที่สุด และรับ Merkle branch ที่เชื่อมโยงธุรกรรมกับบล็อกที่มีการประทับเวลา (Timestamp) อยู่ ถึงแม้ผู้ใช้จะไม่สามารถตรวจสอบธุรกรรมด้วยตัวเองได้ แต่การเชื่อมโยงธุรกรรมกับตำแหน่งในสายบล็อกจะทำให้เห็นว่า node ในเครือข่ายยอมรับแล้ว และบล็อกที่เพิ่มเข้ามาหลังจากนั้นเป็นการยืนยันเพิ่มเติมว่าเครือข่ายยอมรับธุรกรรมนี้แล้ว image การตรวจสอบดังกล่าวจะเชื่อถือได้ตราบใดที่ node ที่ซื่อสัตย์ยังคงควบคุมเครือข่าย แต่จะมีความเสี่ยงมากขึ้นหากเครือข่ายถูกโจมตีและถูกควบคุม ในขณะที่ node ในเครือข่ายสามารถตรวจสอบธุรกรรมได้ด้วยตัวเอง แต่วิธีการแบบง่ายนี้อาจถูกหลอกลวงโดยการใช้ธุรกรรมปลอมของผู้โจมตี ตราบใดที่ผู้โจมตียังคงสามารถควบคุมเครือข่ายได้ กลยุทธ์หนึ่งในการป้องกันปัญหานี้คือ การรับการแจ้งเตือนจาก node อื่น ๆ ในเครือข่ายเมื่อตรวจพบบล็อกที่ไม่ถูกต้อง ซึ่งจะแจ้งให้ซอฟต์แวร์ของผู้ใช้ดาวน์โหลดบล็อกแบบเต็มและธุรกรรมที่แจ้งเตือน เพื่อยืนยันความไม่สอดคล้องกัน ธุรกิจที่ได้รับการชำระเงินบ่อยครั้งอาจยังคงต้องการรัน node ของตนเอง เพื่อความปลอดภัยที่เป็นอิสระและการตรวจสอบที่รวดเร็วยิ่งขึ้น #siamstr
7. Reclaiming Disk Space เมื่อธุรกรรมถูกบรรจุลงในบล๊อกแล้ว สามารถกำจัดธุรกรรมที่ใช้ไปแล้วก่อนหน้านั้นออกได้เพื่อประหยัดพื้นที่ดิสก์ แต่การจะทำอย่างนี้ได้โดยไม่ให้เลข hash ของบล๊อกมีการเปลี่ยนแปลงนั้น ธุรกรรมจึงจำเป็นต้องถูก hash ในรูปแบบของ Merkle Tree [7][2][5] โดยมีแค่ root node ของ tree เท่านั้นที่จะรวมอยู่ใน hash ของบล๊อก นี่เป็นวิธีที่ทำให้สามารถบีบอัดข้อมูลในบล๊อกเก่า ๆ ได้โดยการตัดพวก hash ส่วนอื่น ๆ ของ tree ที่ไม่ใช่ root node ออก (ไม่จำเป็นต้องเก็บ hash ในชั้นอื่น ๆ ของ tree) image โดยในส่วน 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.
6. แรงจูงใจ โดยปกติแล้ว ธุรกรรมแรกของแต่ละบล๊อกนั้นจะเป็นธุรกรรมพิเศษที่จะขุดเหรียญที่สร้างขึ้นใหม่ซึ่งเป็นกรรมสิทธิ์ของผู้สร้างบล็อกนั้น ๆ ซึ่งจะเป็นการเพิ่มแรงจูงใจให้กับ node ต่าง ๆ ในการสนับสนุนเครือข่าย และเป็นวิธีการกระจายเหรียญให้หมุนเวียน เนื่องจากไม่มีหน่วยงานส่วนกลางที่ทำหน้าที่ในการออกเหรียญ การเพิ่มเหรียญใหม่ในปริมาณคงที่อย่างต่อเนื่องนั้นคล้ายคลึงกับการที่คนงานเหมืองทองคำใช้แรง และ เวลา เพื่อเพิ่มทองคำให้หมุนเวียน ในกรณีนี้ คือ เวลา กำลังประมวลผล และไฟฟ้าที่ถูกใช้ไป นอกจากนี้แรงจูงใจจะมาจากค่าธรรมเนียมการทำธุรกรรม หากมูลค่าผลลัพธ์ของธุรกรรมน้อยกว่ามูลค่าที่ใส่เข้ามา ส่วนต่างนั้นก็คือค่าธรรมเนียมการทำธุรกรรมที่จะเพิ่มเข้าไปในมูลค่าแรงจูงใจของบล็อกที่มีธุรกรรมนั้น เมื่อเหรียญทั้งหมดในระบบมีจำนวนเท่ากับที่กำหนดไว้แล้ว แรงจูงใจหลักก็จะถูกเปลี่ยนมาเป็นค่าธรรมเนียมการทำธุรกรรม และปราศจากภาวะเงินเฟ้อโดยสิ้นเชิง แรงจูงใจอาจช่วยกระตุ้นให้ node ต่าง ๆ ยังคงซื่อสัตย์ หากผู้โจมตีที่ละโมบสามารถรวบรวมกำลังประมวลผล ได้มากกว่า node ที่ซื่อสัตย์ทั้งหมด เขาจะต้องเลือกระหว่างการใช้มันเพื่อฉ้อโกงผู้อื่นโดยการใช้จ่ายซ้ำซ้อน หรือใช้มันเพื่อสร้างเหรียญใหม่ พวกเขาจะพบว่าการเล่นตามกฎ กฎที่เอื้อประโยชน์ให้กับเขาด้วยเหรียญใหม่มากกว่าคนอื่น ๆ รวมกันนั้นทำกำไรได้มากกว่าการบ่อนทำลายระบบและความถูกต้องของทรัพย์สินของเขาเอง #siamstr
5. Network เครือข่ายนั้นมีการทำงาน ดังนี้ 1. การประกาศธุรกรรมใหม่: ธุรกรรมใหม่จะถูกประกาศ (broadcast) ไปยังทุก node ในเครือข่าย 2. การรวบรวมธุรกรรม: แต่ละ node จะรวบรวมธุรกรรมใหม่ ๆ เหล่านี้ ไว้ในบล็อก 3. การค้นหา Proof-of-Work: แต่ละ node จะทำการคำนวณ เพื่อค้นหา Proof-of-Work ตามค่า difficulty สำหรับบล็อกนั้น ๆ 4. การประกาศบล็อก: เมื่อ node ใดค้นหา Proof-of-Work ได้แล้ว node นั้นจะทำการประกาศบล็อกไปยังทุก node ในเครือข่าย 5. การตรวจสอบและยอมรับบล็อก: node อื่น ๆ จะทำการตรวจสอบและยอมรับบล็อกนั้น เฉพาะเมื่อธุรกรรมทั้งหมดภายในบล็อกนั้นถูกต้องและยังไม่ถูกใช้มาก่อน 6. การสร้างบล็อกถัดไป: node ต่าง ๆ แสดงการยอมรับบล็อกโดยการเริ่มต้นสร้างบล็อกถัดไปใน chain ด้วย hash ของบล็อกที่ยอมรับ เป็น hash ก่อนหน้าในโครงสร้างของบล๊อกใหม่ที่กำลังสร้าง node ต่าง ๆ จะถือว่า chain ที่ยาวที่สุดเป็น chain ที่ถูกต้องและจะทำงานเพื่อขยาย chain นั้นต่อไป หากมีสอง node ที่ได้ประกาศบล็อกเวอร์ชันที่แตกต่างกันในเวลาพร้อมกัน node บาง node อาจได้รับบล็อกหนึ่งก่อน อีกบล็อกหนึ่ง ในกรณีนี้ node เหล่านั้น จะทำงานบนบล็อกที่ได้รับก่อน แต่จะเก็บสำเนาของบล็อกอีกอันหนึ่งไว้ ในกรณีที่บล็อกนั้น กลายเป็นบล็อกที่อยู่ใน chain ที่ยาวกว่าปัญหาข้อโต้แย้งนี้ก็จะได้รับการแก้ไข เมื่อพบ Proof-of-Work อันถัดไปและ chain ใด chain หนึ่งยาวขึ้น node ที่กำลังทำงานอยู่บน chain ที่สั้นกว่าก็จะเปลี่ยนไปทำงานบน chain ที่ยาวกว่าแทน การประกาศธุรกรรมใหม่ ไม่จำเป็นต้องไปถึงทุก node ในเครือข่าย ตราบใดที่พวกเขายังไปถึง node ส่วนใหญ่ในระบบได้ ธุรกรรมเหล่านั้นก็จะถูกบรรจุอยู่ในบล็อกในไม่ช้า นอกจากนี้การประกาศบล็อกยังไม่ต้องกังวลเรื่องจะมีบล๊อกที่สูญหาย เนื่องจากหากว่า node ไม่ได้รับบล็อกใด ๆ node ก็จะตระหนักได้ว่าพลาดบล็อกก่อนหน้าไปเมื่อได้รับบล๊อกใหม่มา และ node จะทำการร้องขอ block ที่ขาดไปจากเครือข่าย #siamstr