# สถาปัตยกรรมโปรโตคอล

P21 ผสานแกนแบบกำหนดผลได้แน่นอน อะแดปเตอร์หลักฐานเฉพาะแหล่ง และอินเทอร์เฟซส่งมอบแบบบาง ประวัติบล็อกและข้อผูกมัดแบบเลือกใช้ของ Bitcoin เป็นจุดอ้างอิงสาธารณะร่วม โดยแต่ละเอเจนต์ยังคงใช้นโยบายยอมรับของตนเอง

```mermaid
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F7F6F2","primaryTextColor":"#181A18","primaryBorderColor":"#D4D6D1","lineColor":"#666A65","tertiaryColor":"#FFFFFF"}}}%%
flowchart TD
  A[Requester: instruction and policy] --> B[Evidence adapters]
  B --> C[P21 deterministic core]
  C --> D[Findings and evidence bundle]
  D --> E[Consumer verifies]
  E --> F[Local acceptance policy]
  D -. optional .-> G[Asynchronous Bitcoin commitment]
  H[Bitcoin / DMT / TAP] --> B
  I[EVM / signed service artifacts] --> B
```

## องค์ประกอบ

**ตัวเชื่อมหลักฐาน** อ่านหลักฐานต้นฉบับและเก็บชนิด ที่มา เครือข่าย เวอร์ชันแหล่งข้อมูล และเวลาที่สังเกตไว้ ห้ามยกระดับข้อสังเกตจาก RPC ให้กลายเป็นหลักฐานฉันทามติ

**แกนประมวลผล** ตรวจโครงสร้างและการผูกข้อมูล รันนโยบายที่รองรับ และสร้างผลตรวจที่ชัดเจน LLM อาจตีความคำขอหรืออธิบายผล แต่ไม่ตัดสินความถูกต้องทางคริปโทกราฟีและไม่รันคำสั่งตามอำเภอใจจากอาร์ติแฟกต์

**อินเทอร์เฟซผู้จัดทำ** ประกอบหลักฐานกับรายงาน **อินเทอร์เฟซผู้รับ** ตรวจรายงาน ทำซ้ำการตรวจ และใช้นโยบายยอมรับในระบบตนเอง ทั้งสองใช้การตีความที่ระบุเวอร์ชันเดียวกัน

**เวิร์กเกอร์ที่โฮสต์** อาจดึงหลักฐาน จัดการงาน และส่ง callback แต่ไม่มีอำนาจเหนือเงินลูกค้าใน Alpha

## ขอบเขต

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

ช่องทางส่งหลักฐาน รางชำระเงิน และเชนที่ดำเนินงานอาจต่างกัน แต่ละส่วนคงสมมติฐานความเชื่อถือและความยืนยันขั้นสุดท้ายของตน

<!-- p21-source-payment-v08 -->

## การแก้ความหมาย DMT โดยไม่ต้องสร้างโทเคน

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

องค์ประกอบแหล่งข้อมูล P21 **จะประกาศภายหลัง** หน้านี้ไม่เปิดเผยข้อความลงทะเบียน ฟิลด์หรือรูปแบบที่เลือก ชื่อที่สงวน หรือ ID ของ inscription การใช้องค์ประกอบเดิมที่ถูกต้องทำได้ และโปรโตคอลไม่ได้บังคับให้สร้าง inscription ใหม่ในชื่อแบรนด์

`ord-tap` แบบทำงานอิสระของ Trac มีระบบดัชนีที่นำกลับมาใช้ได้ ตัวแยกวิเคราะห์เวอร์ชันที่ตรึงรองรับฟิลด์ 4, 10 และ 11 ตรวจการเปิดใช้กฎ ปรับชื่อเป็นรูปแบบมาตรฐาน ตรวจรูปแบบ และปฏิเสธทั้งชื่อซ้ำและลายเซ็นฟิลด์/รูปแบบซ้ำ การเปลี่ยนชื่อไม่ได้ทำให้ลงทะเบียนนิยามทั้งฟิลด์ที่มีอยู่แล้วได้ โค้ดที่ตรวจไม่มีกระบวนการอนุมัติโดยทีม แต่ความถูกต้องยังขึ้นอยู่กับการตรวจประวัติตามกฎ ไม่ใช่เพียงการอยู่ใน Bitcoin สิทธิ์ใช้ผู้ให้บริการโฮสต์และเงื่อนไขบริการเป็นอีกเรื่องหนึ่ง [1][2][6]


## แยกการตีความ การลงทะเบียน และกรรมสิทธิ์

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

ตรึงแฮชเนื้อหา inscription โปรไฟล์แหล่งข้อมูล เวอร์ชันต้นน้ำ เครือข่าย แฮชและความสูงบล็อก การเข้ารหัสมาตรฐาน การดำเนินการ พารามิเตอร์ commitment ของอินพุต และผลลัพธ์ ระบุขอบเขตหลักฐานและข้อจำกัด ข้อมูลที่ขาดหรือรูปแบบที่ไม่รองรับให้ผล INDETERMINATE ไม่ใช่สร้างผลว่าถูกต้อง แยกข้อมูลที่ดัชนีรายงานจากสถานะที่เล่นซ้ำโดยอิสระ การใช้ฟิลด์ Bitcoin โดยตรงแทนต้องไม่แอบนับเป็นการตรวจทะเบียน DMT ที่ยังไม่ได้ทำ


[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559

<!-- p21-enforcement-v10 -->

## จากหลักฐานสู่การบังคับใช้แบบเลือกได้

Proof21 แยก **โหมดหลักฐาน** ออกจาก **โหมด execution gate** แบบเลือกใช้ โหมดหลักฐานสร้างและตรวจรายงานโดยไม่ควบคุมกระเป๋า ส่วนโหมด gate ทำให้ signer, wallet หรือสิทธิ์ API ที่ได้รับการป้องกันเข้าถึงได้ผ่าน policy gate เท่านั้น คำตอบจากโมเดลไม่ใช่อำนาจใช้จ่ายขั้นสุดท้าย

ก่อนดำเนินการ gate จะคำนวณ `actionDigest` ของคำสั่งจริงอีกครั้งและตรวจ request, policy, network, asset เมื่อเกี่ยวข้อง, nonce และอายุการใช้งาน การอนุญาตสำหรับ action A ใช้แทน action B ไม่ได้ การตัดสินใจ `ACCEPT / REJECT / REVIEW` ที่ผู้รับลงนามภายหลังเป็นหลักฐานคนละชิ้นและไม่สามารถเขียนทับ integrity, deterministic evaluation หรือ settlement ที่ยืนยันอย่างอิสระได้ รุ่นนี้เป็นข้อกำหนดเท่านั้น ยังไม่มี P21 policy signer หรือ custody path สำหรับ production