
เราทดลองใช้งานจริงบนโหนด ECN ภูมิภาคของ PolitiCap สองแห่ง — ขอบ LAN ที่เร็ว (กรุงเทพฯ) และขอบ WAN ที่ช้า (เบอร์ลิน) เป้าหมายไม่ใช่ปริมาณการตลาด แต่คือการวัดพฤติกรรมของ MarketMaker, การปิดผนึกบัญชีแยกประเภท DutchBud, การอัปโหลดแบบชุด, การปฏิเสธตราประทับปลอม และการกักกันผู้ให้บริการโหนดภายใต้โหลดจริง
นี่คือบทความ วิศวกรรม ของ 3DN: ตัวเลขจากคลังเมตริก พฤติกรรมที่สังเกตได้ และการออกแบบที่ยืนหยัดได้ ต่อเนื่องจากเรื่อง pull ไม่ push สำหรับอัปเดตโหนดภูมิภาค และชุดคำสั่งซื้อที่ผูกกับ ledger
ทำไม latency ของ ECN ยังสำคัญ (ย้อนประวัติสั้นๆ)
เครือข่ายสื่อสารอิเล็กทรอนิกส์ไม่ใช่แนวคิดใหม่ ตลาดหุ้นเรียนรู้มานานหลายทศวรรษว่า ใครเห็นสมุดคำสั่งก่อน คืออาวุธทางเศรษฐกิจ ตลาดหลักทรัพย์เบอร์ลินและเวทียุโรปอื่นๆ ถูกพูดถึงในบริบทของใบเสนอราคาที่ล่าช้า สภาพคล่องที่กระจัดกระจาย และรูปแบบ short selling ที่อาศัยความได้เปรียบเมื่อเส้นทางหนึ่งช้ากว่าอีกเส้นทาง เรื่องอื้อฉาวเรื่อง naked short และการส่งมอบล้มเหลวไม่ใช่แค่ความโลภ — แต่เป็น ข้อมูลที่ไม่สมมาตรตามเวลา
PolitiCap เป็นจำลองตลาดพลเมืองด้วย เครดิตเสมือน (dibs ของ DutchBud) ไม่ใช่ตลาดหลักทรัพย์เงินสด แต่บทเรียนวิศวกรรมยังใช้ได้: ถ้าโหนดภูมิภาคแต่ง fills ให้ฮับเชื่อได้ หรือใช้ lag เป็นมุมมองพิเศษบนเทป คุณกำลังสร้างปัญหา ECN เก่าในขนาดย่อ การทดลองของเราจงใจเน้นตรงข้าม — เฉพาะชุดที่ปิดผนึก, ซอฟต์แวร์แบบ pull และการกักกันเมื่อตราประทับล้มเหลว
สิ่งที่เราทดสอบ
| การทดลอง | ลักษณะขอบ | รูปโหลด | คู่แข่งจำลอง |
|---|---|---|---|
| กรุงเทพฯ | เส้นทางระดับ LAN ไปฮับ | Volume MM จากเบา → ปานกลาง ~1 ชั่วโมง | แถว ledger ปลอมใน outbox ท้องถิ่นเป็นระยะ |
| เบอร์ลิน | ขอบ WAN (ดึงซอฟต์แวร์ช้า ระดับ kB/s) | ระเบิดสั้นที่ปิดผนึกแล้ว (~3 นาที, 28 fills) | ฉีดตราปลอมแบบเดียวกัน; เส้นทาง auto-quarantine |
ทั้งสองโหนดใช้กฎเดียวกัน: การจับคู่ท้องถิ่นอยู่ที่โหนด; การส่งต่อไปฮับต้องมีใบเสร็จ DutchBud (ledger_ref + HMAC ledger_code) ฮับไม่ยอมรับเพราะ “โหนดบอกอย่างนั้น”
กรุงเทพฯ — เพิ่มโหลดบนเส้นทางสะอาด
การตั้งค่า. บอท MarketMaker สองตัวครอสสัญลักษณ์ทดลองบน API กรุงเทพฯ ปริมาณเฉลี่ยจากเบา (~8 หุ้น/นาที) ไปปานกลาง (~40 หุ้น/นาที) ประมาณหนึ่งชั่วโมง พร้อม noise เล็กน้อยบนราคาและ lot
ผลการส่งต่อ. เมตริกฮับและตาราง syndicated trades สอดคล้องกัน: ในระดับ ~580 fills ที่เชื่อถือด้วย ledger จากโหนดกรุงเทพฯ บนเทปฮับ (ป้าย trust ledger) อัปโหลดชุดทุกนาที
คู่แข่งจำลอง. โพรเซสแยกฉีดแถว outbox ด้วย ledger อ้างอิง/รหัสที่เดา ฮับปฏิเสธ — ไม่เคยขึ้นเทปฮับ นั่นคือจุดของการผูกชุดกับใบเสร็จ DutchBud
CPU. ที่อัตรานี้ไม่เห็น spike compute ที่น่าเป็นห่วง HMAC-SHA256 ถูกเมื่อเทียบกับ commit ฐานข้อมูล — คนละรูปกับ proof-of-work ที่ต้องแฮชล้มเหลวนับไม่ถ้วน
เบอร์ลิน — ขอบ WAN, ระเบิดสั้น, กักกัน
ขอบ. โหนดเบอร์ลินอยู่บน WAN ที่จำกัด การดึงไบนารีช้ามาก (kB/s) เหมาะกับ JSON ไม่เหมาะกับไฟล์ใหญ่หลายเมกะไบต์ ความคาดหวัง production ยังเป็น pull; ฟิสิกส์ของ WAN ยังอยู่
โหลด. ระเบิดสั้นให้ 28 การครอสที่ปิดผนึกในท้องถิ่นภายในไม่กี่นาที
ชุดแรก. ฮับรับแถวที่ปิดผนึกและปฏิเสธแถวปลอม
กักกัน. สัญญาณตราปลอมชัดทำให้ฮับกักกันโหนดเบอร์ลินอัตโนมัติ: ปฏิเสธ POST ชุดถัดไปด้วย 403, ส่งอีเมลด่วนถึงผู้ให้บริการที่ลงทะเบียน, ไม่จงใจหน่วงการจับคู่ท้องถิ่น (การหน่วงลูกค้าเป็นยาพิษที่ผู้ไม่หวังดีใช้ได้)
การยกเลิกกักกัน. หากยังมีแถว rogue ค้างใน outbox คู่กับใบเสร็จที่ถูกใช้แล้ว การ flush ถัดไปอาจจุดกักกันอีกครั้ง — เราปรับให้ auto-quarantine ทำงานเมื่อ rejects ทั้งชุดเป็นแบบ rogue เท่านั้น และควรล้าง outbox หลังเหตุการณ์
เมตริกบอกอะไร
- เกจตัวตนโหนด (เวอร์ชันที่รัน vs ล่าสุดของฮับ, hello ล่าสุด) ต่อเนื่องเมื่อทั้งสองโหนดรายงานบิลด์ทดลอง
- ตัวนับ ingest ของฮับแยก legit/rogue และ accepted/rejected
- ตัวนับอัปโหลดฝั่งโหนดอยู่บนโพรเซสโหนด — ขอบ WAN ที่ไม่ได้ scrape จะไม่โชว์บนแผง “node upload” แม้ล็อกจะมี POST ทุกนาที; ingest ของฮับคือแหล่งความจริง
- การ retry ช่วงกักกันทำให้ยอด reject พอง — ตาราง syndicated trades ไม่โตตาม
ข้อสรุปการออกแบบ
- Pull ยังชนะ บนเครือข่ายช้าหรือที่ไม่ได้ถือคีย์ครบ
- ตราประทับคือรากความเชื่อถือ; API key เป็นเพียงปาก — curl ก็ POST ได้; มีแค่ HMAC ของ DutchBud ที่ทำให้คำมีน้ำหนักบนเทปฮับ
- กักกัน uplink + อีเมล ไม่ใช่ DoS ลูกค้าท้องถิ่น
- บทเรียน ECN lag ในประวัติศาสตร์ เตือนไม่ให้สร้างเทปที่ไร้ตรา
- สุขอนามัย ops สำคัญเท่าคริปโต — ล้าง outbox ปลอมก่อนยกเลิกกักกัน
PolitiCap อยู่ใน ครอบครัว 3DN — งาน · เงิน · การเมือง — โดย DutchBud เป็น ledger วงปิดสำหรับเครดิตเสมือน หากคุณต้องรักษาระบบให้ซื่อสัตย์ข้ามเครือข่ายที่คุณไม่ได้เป็นเจ้าของทั้งหมด pull-plus-seal เป็นแพทเทิร์นที่คุ้มค่าต่อการนำไปใช้
ใส่ความเห็น