อ้างอิง / หลักฐาน

วิธีการทำงานของหลักฐาน

อธิบายเกี่ยวกับโซ่แฮช (hash chain), ลายเซ็น (signatures), จุดตรวจสอบ (checkpoints) และพยาน (witnesses) ด้วยสูตรที่ผู้ตรวจสอบใช้จริง

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

เว็บไซต์เอกสารท้องถิ่นนี้ยังเพิ่ม ตัวอย่างแบบโต้ตอบที่ /docs/concepts/ และเครื่องมือสำรวจการตัดสินใจที่จุดตรวจสอบ (checkpoint) ที่ /docs/witness/ ทุกข้อความตัวอย่าง, จำนวน และระยะเวลาล่าช้า เป็นข้อมูลสมมติทั้งหมด ค่าแฮชในแซนด์บ็อกซ์ของเชนถูกคำนวณด้วย SHA-256 ในเบราว์เซอร์ ไม่มีข้อมูลใดถูกส่งไปยัง Telegram

ข้อความเปลี่ยนแปลง; ข้อมูลการสังเกตถูกสะสม#

แผนภาพในรูปแบบข้อความ

Telegram → Collector: ข้อความใหม่: พบกันเวลา 10:00
Collector → บันทึกที่ลงนาม: เพิ่ม message.new
Telegram → Collector: แก้ไข: พบกันเวลา 11:00
Collector → บันทึกที่ลงนาม: เพิ่มข้อความ.edited
Telegram → Collector: ประกาศการลบ
Collector → บันทึกที่ลงนาม: เพิ่มข้อความ "message.deleted"
หมายเหตุเกี่ยวกับบันทึกที่ลงนาม: การสังเกตข้อความต้นฉบับ + การแก้ไข + การลบ ยังคงอยู่

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

ข้อมูลที่แฮชครอบคลุม#

สังเกต รหัส แฮช และลงลายมือชื่อ: ทุกเหตุการณ์ใหม่จะรวมแฮชของเหตุการณ์ก่อนหน้านั้นไว้ด้วย

อ่านสูตรจากภายในสู่ภายนอก: C แปลงสนามทั้งเก้าเป็นไบต์ที่แม่นยำ; SHA-256 สร้างค่าสรุป (digest) ของสนามเหล่านั้น; hex คือวิธีการเก็บค่าสรุปนั้นไว้ ส่วนค่าแฮช ก่อนหน้านี้มีอยู่ในเหตุการณ์แล้ว unhex แปลงค่าแฮชที่เก็บไว้กลับเป็น 32 ไบต์ที่ Ed25519 ใช้ลงนาม

แผนภาพโซ่แบบคงที่

ให้ C(e_i) เป็น JSON UTF-8 แบบมาตรฐานของสนามเหตุการณ์ทั้งเก้า สนามแรก previous_hash ประกอบด้วยตัวอักษรศูนย์ 64 ตัว แต่ละบันทึกถัดไปจะรวมแฮชแบบฐานสิบหก ของบันทึกก่อนหน้า:

h_i = hex(SHA256(C(e_i)))

σ_i = Ed25519.Sign(sk,unhex(h_i))

ลายเซ็นครอบคลุม 32 ไบต์ของดิบไดเจสต์ ข้อมูลแฮชที่ป้อนเข้าประกอบด้วยค่า seq, observed_at, source_at, kind, chat_id, message_id, actor_id, payload และ previous_hash เท่านั้น คีย์ของอ็อบเจ็กต์ถูกจัดเรียงตามลำดับ; ช่องว่างและ ASCII escaping ถูกละเว้น; NaN และ infinity ถูกปฏิเสธ ดู การเข้ารหัสที่แม่นยำ

แผนภาพในรูปแบบข้อความ

64 ตัวอักษรศูนย์ → บันทึก 1 / hash h1
บันทึก 1 / hash h1 → บันทึก 2 รวมถึง h1 / hash h2
บันทึก 2 รวมถึง h1 / hash h2 → บันทึก 3 รวมถึง h2 / hash h3
บันทึก 3 รวมถึง h2 / hash h3 → จุดตรวจสอบที่ลงนาม: count 3, head h3 (เก็บไว้ที่อื่น)

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

การเปลี่ยนข้อมูลในฟิลด์ที่บันทึกไว้จะส่งผลให้ค่า digest เปลี่ยนแปลง; การสร้างค่า hash ใหม่จะไม่คืนค่าลายเซ็นเดิม

ลองใช้ตรรกะนี้กับบันทึกที่ 2: เปลี่ยน Meet at 11:00 เป็น Meet at 12:00 ใน เหตุการณ์ที่บันทึกไว้ ค่าแฮชที่คำนวณใหม่จะไม่ตรงกันอีกต่อไป การคำนวณใหม่ของโซ่ข้อมูลที่ตามมา สามารถซ่อมแซมลิงก์ได้ แต่ไม่สามารถทำให้ลายเซ็นเดิมครอบคลุมค่าแฮชใหม่ได้ ในทางตรงกันข้าม การแก้ไขข้อความ Telegram ที่ถูกสังเกตเห็นจะกลายเป็นบันทึกใหม่ในสมุดบันทึก

แผนภาพการเปลี่ยนแปลงแบบคงที่

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

สิ่งที่จุดตรวจสอบก่อนหน้านี้เพิ่มเข้ามา#

เก็บจำนวน 3 และหัวข้อ h3; การส่งออกข้อมูล 4 รายการในภายหลังจะถูกตรวจสอบที่ตำแหน่ง 3.

จุดอ้างอิงจะคงที่ในขณะที่บันทึกหลักฐานขยายตัว หากจุดตรวจสอบระบุว่า “3 records, head h3” การส่งออกข้อมูล 4 รายการสามารถผ่านได้โดยการจับคู่ h3 ที่ตำแหน่งที่ 3 ส่วนหัวล่าสุดคือ h4 ซึ่งคาดว่าจะแตกต่างออกไป การส่งออกข้อมูลเพียง 2 รายการจะล้มเหลว

แผนภาพจุดตรวจสอบแบบคงที่

หลังจากตรวจสอบลายเซ็นของจุดตรวจสอบแล้ว ให้ดำเนินการดังต่อไปนี้:

N_export ≥ N_checkpoint and h_export[N_checkpoint] = H_checkpoint

การส่งออกข้อมูลอาจขยายเกินจุดตรวจสอบ (checkpoint) แต่ต้องตรงกันที่ขอบเขตที่เก็บไว้ ผู้ตรวจสอบจริงยังตรวจสอบลำดับของทุกเหตุการณ์ ลิงก์ก่อนหน้า ค่าแฮช และ ลายเซ็นด้วย การเปรียบเทียบเพียงส่วนหัว (head) ที่เก็บไว้สุดท้าย อาจทำให้พลาดบันทึกภายในที่ถูกแก้ไข ซึ่งค่าแฮชที่เก็บไว้ยังไม่ได้รับการอัปเดต

ที่ที่พยานควรอยู่#

แผนภาพในรูปแบบข้อความ

Collector / account session / key A → จุดปลายทางจุดตรวจสอบแบบอ่านอย่างเดียว
Witness / กุญแจผู้เก็บข้อมูลที่ตรึงไว้ / กุญแจส่วนตัว B → สมุดบันทึกพยานที่ลงนามแยกต่างหาก
Witness / กุญแจผู้เก็บข้อมูลที่ตรึงไว้ / กุญแจส่วนตัว B → จุดปลายทางจุดตรวจสอบแบบอ่านอย่างเดียว (ขอตรวจสอบ)
จุดปลายทางจุดตรวจสอบแบบอ่านอย่างเดียว → Witness / กุญแจผู้เก็บข้อมูลที่ตรึงไว้ / กุญแจส่วนตัว B (คำตอบที่ลงนาม)
Witness / กุญแจผู้เก็บข้อมูลที่ตรึงไว้ / กุญแจส่วนตัว B → ช่องที่มีโพสต์ TGW1 ที่ลงลายมือชื่อ (Bot API / โทเคนส่วนตัว)

บันทึกของพยานจะบันทึกการย้อนกลับ (rollback), การเปลี่ยนหัวบันทึก (head) ที่จำนวนเดียวกัน, การเปลี่ยนกุญแจ, คำตอบที่ไม่ถูกต้อง และคำตอบที่ขาดหายไป การมีจำนวนบันทึกที่มากขึ้นเพียงอย่างเดียวไม่สามารถยืนยันได้ ว่าบันทึกทุกฉบับก่อนหน้านี้ยังคงไม่เปลี่ยนแปลง; ให้เปรียบเทียบไฟล์ที่ส่งออกกับ จุดตรวจสอบ (checkpoints) ที่เก็บไว้ พยานที่ติดตั้งบนโฮสต์อื่นจะช่วยหลีกเลี่ยงการได้รับผลกระทบจาก การหยุดทำงานของโฮสต์ผู้เก็บข้อมูล; ผู้ดำเนินการที่แยกต่างหากจะให้ความอิสระเพิ่มเติม

Witness ยืนยันสถานะของบันทึกที่ผู้เก็บข้อมูลรายงานมา มันไม่ได้ สังเกตการณ์ข้อความ Telegram ทั้งหมดอย่างอิสระ ดูการตั้งค่า Witness

ทดสอบการส่งข้อมูลตามการดำเนินการที่ทราบ#

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

R = |observed∩expected| / |expected| Δ t = t_receipt - t_action

นับเฉพาะการดำเนินการที่ตรงกับที่คาดไว้เท่านั้น; ใบเสร็จที่ซ้ำกันจะไม่เพิ่ม ตัวเศษ ส่วนตัวส่วนต้องไม่เท่ากับศูนย์ ใบเสร็จที่ขาดหายไปจะไม่มี ความล่าช้าที่วัดได้ บันทึกความไม่แน่นอนของเวลา; ใช้เวลาการลบที่ควบคุมได้ของคุณเอง เนื่องจาก Telegram ไม่ให้เวลาการลบที่แม่นยำ ผลลัพธ์เช่น 5/6 (83.3%) อธิบายการดำเนินการทดสอบ ไม่ใช่ความครบถ้วนของข้อมูลการสื่อสารทั้งหมดใน Telegram

เลือกขั้นตอนการทำงาน#

ขั้นตอนการสืบสวนอย่างละเอียดจะติดตามเหตุการณ์ ที่เกิดขึ้นในช่อง (channel), กลุ่ม (group), บอท (bot) และการสนทนาส่วนตัว:

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

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

การตรวจสอบความถูกต้องที่เสร็จสิ้นแล้วและงานที่ยังเหลือ · ส่งออกและตรวจสอบ · เริ่มต้นด้วยบัญชีเดียว