1 · 애플리케이션 레이어
2 · 네트워크 레이어
3 · 실행 레이어
4 · 상태 레이어
런타임은 프로토콜 바깥에 있다그리고 아무 특권도 갖지 않습니다 — 더 낮은 지연도, 더 이른 데이터도, 제3자가 닿을 수 없는 인터페이스도 없습니다
발신자가 agent일 때의 수용늦은 취소가 늦은 주문보다 나쁘고, 공정성은 메시지별이 아니라 최근 이력으로 추적됩니다
인가는 트랜잭션이다블록 높이를 갖고 닫힌 명령어 집합 안에 있습니다. 그리고 인가를 철회하면 그 agent의 대기 주문이 같은 블록에서 취소됩니다
리플레이 가능한, 블록 단위로 버전이 매겨진 환경point-in-time이 규율이 아니라 구조로 보장됩니다
아키텍처 개요와 같은 네 레이어입니다. 다른 것은 질문뿐입니다 — 참여자가 사람이 아닐 때 각 레이어는 무엇을 해야 하는가.
1 · 애플리케이션 레이어 — 런타임은 바깥에 있고, 그래야만 한다
에이전트 런타임은 리서치와 실행의 프레임워크입니다. 견해를 만들고, 그것을 실행 가능한 것으로 바꾸고, 거래 장소 앞에 내놓습니다. 프런트엔드나 API 클라이언트와 같은 층, 즉 애플리케이션 레이어에서 돌며 프로토콜의 일부가 아닙니다. 이 위치는 설계 취향이기 이전에 물리적 제약입니다. 모델은 초 단위로 추론하고 시장은 밀리초 단위로 움직입니다. 모델을 호출해야 하는 것은 주문이 실제로 지나는 경로 위에 놓일 수 없습니다. 다시 말해 프로토콜에는 모델이 전혀 없습니다 — 누락이 아니라, 결제 경로 위의 모델이 여기 나머지 전부가 딛고 선 그 하나의 성질을 무너뜨리기 때문입니다. 실행 경로는 모든 노드에서 같은 바이트를 내야 하고, 추론은 그렇게 하지 못합니다. 그래서 런타임은 바깥에 있고, 정직한 질문은 프로토콜이 런타임에 무엇을 빚지고 있는가로 바뀝니다. 다섯 가지이며 모두 제공됨이 아니라 커밋됨입니다.
상태는 다음 단계를 보십시오.
런타임은 특권 경로를 갖지 않습니다. 더 낮은 지연도, 더 이른 데이터도, 제3자 런타임이 닿을 수 없는 인터페이스도 없습니다. 이는 전제하지 말고 명시할 가치가 있습니다. 이 아키텍처가 다른 곳에서 하는 주장은 「트레이더와 클리어링 하우스 사이에 아무것도 서지 않는다」이고, 전용 차선을 가진 자사 도구야말로 바로 그 「무엇」이기 때문입니다.
2 · 네트워크 레이어 — 발신자가 에이전트일 때의 수용
멤풀은 무엇을 보관할 가치가 있는지, 어떤 발신자의 어느 트랜잭션이 다음인지, 어떤 피어가 그것을 듣는지, 수요가 용량을 넘을 때 무엇을 버릴지를 정합니다. 에이전트 흐름은 이 넷 모두에 부담을 주고, 그것을 흡수하는 성질 중 둘은 에이전트 이전의 이유로 이미 자리잡고 있습니다. 늦은 취소가 늦은 주문보다 나쁩니다. 멤풀은 설계상 주문과 취소 트래픽을 비대칭으로 다룹니다. 에이전트는 취소 대 체결 비율이 사람보다 높아 그 비대칭을 더 극단으로 만들지만, 문제의 형태 자체는 이 레이어가 애초에 그 주위로 만들어진 것입니다. 공정성은 메시지별이 아니라 최근 이력으로 추적됩니다. 멤풀은 최근 어떤 발신자와 어떤 종류의 트래픽이 용량을 소비했는지에 대한 롤링 기록을 유지하고, 그에 따라 다음에 무엇을 내보낼지 조정합니다. 상관된 버스트에서 중요한 부분이 바로 여기입니다: 마흔 개의 에이전트가 같은 신호에 취소하는 것은 평균 부하의 마흔 배가 고르게 퍼진 것이 아니라 하나의 스파이크입니다. 메시지별 제한은 그것을 놓칩니다. 최근 누가 시끄러웠는지에 대한 기억은 놓치지 않습니다. 합의는 처리량과 함께 커지지 않습니다. 트랜잭션은 배치로 검증자에게 도달하고, 제안이 그것을 참조하기 전에 가용성이 증명되므로 블록 제안은 본문이 아니라 다이제스트를 나릅니다. 메시지 속도를 한 자릿수 올리는 에이전트 집단이 있어도 합의 메시지 크기는 전혀 올라가지 않습니다. 이 레이어에서 두 질문이 열려 있고, 둘 다 사람의 물량이 아니라 에이전트의 물량에서 비로소 실질적인 문제가 됩니다. 취소는 얼마여야 하는가. 실행 레이어는 이미 취소를 앞세웁니다 — 유동성을 가져갈 수 있는 무엇보다 앞선 단계에서 돕니다. 네트워크 레이어에서의 같은 질문은 미정입니다. 싸고 우선되는 취소야말로 「호가를 지킬 수 있다」의 근원이며, 동시에 멤풀을 채우는 가장 싼 방법이기도 합니다. 취소가 주문과 별개의 용량 계정을 가져야 하는지는 정해지지 않았습니다. 멱등성은 어느 레이어의 것인가. 응답을 받지 못한 에이전트는 재전송합니다. 멱등 제출은 실행 레이어에서 커밋되었고, 정말 중요한 귀결 — 중복 익스포저 없음 — 을 정리합니다. 그러나 네트워크 레이어 버전은 정리하지 못합니다. 멤풀이 재전송을 같은 의도로 인식해야 하는지, 아니면 둘 다 나르고 실행 레이어가 중복을 제거하게 해야 하는지. 재시도 폭풍 아래에서 이 둘은 다르게 동작합니다.의도적으로 목록에 넣지 않은 것이 하나 있습니다. 에이전트 전용 수용 통로입니다. 우선 접근은 모든 중앙화 거래 장소가 결국 파는 것이고, 「트레이더와 클리어링 하우스 사이에 아무것도 서지 않는다」는 주장과 정면으로 충돌합니다. 에이전트 흐름도 같은 문을 지납니다.
3 · 실행 레이어 — 인가는 트랜잭션이다
여기가 계정 모델이 바뀌는 레이어이고, 그 변화 전부는 하나의 사실에서 따라 나옵니다. 계정을 에이전트에게 넘기는 것은 온체인 트랜잭션입니다. 양식 제출도, 설정 페이지에서 발급한 API 키도, 운영자 데이터베이스의 한 행도 아닙니다. 트랜잭션입니다 — 블록 안에, 높이를 갖고, 그것을 부여한 계정이 서명한. 따라서 제3자는 누구에게도 묻지 않고 그것을 찾고, 읽고, 확인할 수 있습니다. 여기서 세 가지 귀결이 따라 나오고, 각각은 API 키가 할 수 없는 일입니다. 그것은 닫힌 명령어 집합 안에 있습니다. 에이전트 인가는 커널의 열거된 연산 중 하나입니다. 범용 체인은 이를 표현하지 못합니다 — 그 호출의 의미가 불투명한 바이트코드가 되기 때문입니다. 중앙화된 장소는 당신이 들여다볼 수 없는 소프트웨어 안에서 그것을 강제합니다. 여기서는 권한과 그 경계가 명령어 그 자체이고, 그래서 경계는 약속이 아니라 확인 가능한 것입니다. 에이전트가 무엇을 해도 되는지는 담지만, 무엇을 하면 안 되는지는 담지 못합니다. 인가는 그 에이전트가 얼마를 보유하고, 얼마를 잃고, 어느 마켓을 건드리고, 증거금 모드를 바꿔도 되는지를 말할 수 있습니다. 「출금」은 말할 수 없습니다. 이는 기본값이 꺼져 있는 것이 아니라, 쓸 항목 자체가 없다는 뜻입니다. 계정을 운용하는 에이전트에게는 자금을 밖으로 옮길 표현 가능한 경로가 없습니다. 철회하면 그 에이전트의 대기 주문도 취소됩니다. 철회 역시 트랜잭션이고, 시퀀싱이 이미 「취소는 유동성을 가져갈 수 있는 무엇보다 먼저 돈다」고 정해 둔 블록에 안착합니다. 그래서 에이전트가 오더북에 남긴 주문은 그 권한과 같은 블록에서 함께 사라집니다. 철회가 데이터베이스 쓰기인 장소에서는 키가 작동을 멈추고 대기 주문은 정의되지 않은 상태에 놓입니다. 여기서는 그 정지가 증명 가능하고, 그것이 일어난 높이를 누구나 찾을 수 있습니다.부여블록 N의 트랜잭션범위를 담습니다. 그 agent가 무엇을 보유하고, 얼마를 잃고, 무엇을 거래할 수 있는지. 출금은 담을 수 없습니다 — 그런 항목이 아예 없습니다
실행모든 동작이 권한의 출처를 밝힌다제출한 agent뿐 아니라 그것을 부여한 계정에 귀속됩니다
철회블록 M의 트랜잭션그 agent의 대기 주문은 같은 블록에서, 유동성을 가져갈 수 있는 무엇이든 실행되기 전에 취소됩니다
셋 중 어느 것도 누가 알려 주어야 아는 데이터베이스 쓰기가 아닙니다. 모두 누구나 높이로 찾을 수 있는 트랜잭션입니다.
장소가 이미 런타임 대신 짊어지고 있는 것
보통의 장소에서 사용자를 지켜야 하는 트레이딩 런타임은 결국 자기만의 특권 코어를 만들게 됩니다. 자기가 유지하고 대사하는 포지션 원장, 자기가 돌리고 장소도 같게 계산하기를 바라는 사전 리스크 검사, 자기가 쓰고 변조되지 않았음을 증명할 수 없는 감사 로그. 셋 다 장부를 보여 주지 않는 장소에 대한 이중화입니다. 여기서는 그중 셋이 프로토콜 성질입니다. 원장을 쓰는 것은 클리어링 하우스뿐입니다. 리스크 단계는 매칭보다 먼저, 같은 블록 안에서 돕니다. 감사 로그는 체인 자체이고, 모든 상태 변경이 그것을 일으킨 트랜잭션을 함께 지닙니다. 런타임에 남는 것은 넷째 — 멱등 주문 게이트웨이 — 이고, 그것은 신뢰의 문제가 아니라 인터페이스의 문제입니다.매칭: 블록이 이미 배치다
에이전트 흐름은 오더북에 닿는 것의 빈도를 높이고 크기를 낮춥니다. 이는 배치 옥션을 논할 때 가장 자주 동원되는 바로 그 미시구조입니다 — 이산 구간, 함께 청산, 1마이크로초 먼저 도착해도 이점 없음. 그 성질은 여기서 이미 성립하며, 배치 옥션을 더해서가 아닙니다. 블록 안의 시간은 로컬 시계가 아니라 합의가 커밋한 위치이므로 블록 안에는 밀리초 이하의 이점이 존재하지 않습니다. 그리고 취소는 어떤 공격적 주문보다 먼저 돌기 때문에, 낡은 호가는 거둘 수 있고 함께 도착한 주문에 먹히지 않습니다. 블록은 함께 청산되는 이산 구간입니다. 그것은 시장 설계의 덧붙임이 아니라 커밋된 순서를 실행한 결과로 나타났습니다. 그 이상이 정당한지 — 그리고 연속 가격·시간 우선과 빈번한 배치 옥션은 배치가 배치 안의 시간 우선을 의도적으로 없애는 이상 더하기가 아니라 양자택일입니다 — 는 구축 중이 아니라 탐색 중입니다.4 · 상태 레이어 — 체인이 곧 환경이다
에이전트의 좋고 나쁨은 무엇을 상대로 평가되었는가로 정해지고, 실패의 대부분은 바로 그 평가에서 일어납니다. 시뮬레이터에서 수익이 나고 프로덕션에서 실패하는 전략은 대개 새로운 시장을 만난 것이 아니라, 거래 장소가 아닌 시뮬레이터를 만난 것입니다. 상태 레이어는 그 간극을 규율이 아니라 구조로 없앱니다. 상태는 블록 단위로 버전이 매겨지고 모든 변경은 그것을 일으킨 트랜잭션에 귀속되므로, 블록을 리플레이하는 것은 환경의 모델이 아니라 환경 자체를 리플레이하는 것입니다 — 그 에이전트를 실제로 실행할 바로 그 상태 기계 위에서, 네트워크가 커밋한 입력으로. 이것이 직접 검증하기의 다섯 번째 점검이며, 여기서의 백테스트가 거래소 과거 API를 상대로 한 백테스트와 다른 종류의 것인 이유입니다. 더 미묘한 성질은 이것이 구조에 의한 point-in-time이라는 점입니다. 거래소 API로 조립한 데이터셋은 조립한 사람이 신중했을 때만 point-in-time이고, 룩어헤드는 아무도 눈치채지 못한 틈으로 새어 듭니다 — 나중에 채워 넣은 필드, 과거에 적용된 정정, 수정된 기준 가격. 여기서는 그 질문이 생기지 않습니다. 어떤 블록의 상태는 그 블록에서 참이었던 것이고, 상태는 애초에 그 형태 말고는 가져 본 적이 없기 때문입니다.더 어려워지는 것
에이전트를 위해 만든다는 것은 좋아지는 것들의 목록만은 아닙니다. 결정성은 양날입니다. 에이전트는 제출 전에 자기 주문이 무엇을 할지 예측할 수 있습니다. 같은 입력이 모든 노드에서 같은 결과를 내기 때문입니다. 다른 사람의 에이전트도 당신의 주문에 대해 그럴 수 있습니다. 재현 가능성은 당신의 계획 능력과 예측 가능성을 동시에 올리고, 뒤쪽은 공짜가 아닙니다. 에이전트의 유동성은 상관된 유동성입니다. 사람 마켓메이커는 알아차리는 시점이 달라서 물러나는 시점도 다릅니다. 같은 공개 상태를 읽는 에이전트들은 함께 같은 결론에 도달합니다. 에이전트가 받치는 오더북은 평범한 날에는 더 두껍고, 정작 중요한 날에는 더 빨리 얇아질 수 있습니다 — 이는 프로토콜의 흡수층이 대비하도록 설계된 시장 구조 리스크이지, 그것들이 없앨 수 있는 리스크가 아닙니다. 오라클이 읽는 장소에서 에이전트도 거래합니다. 인증은 가격을 그것을 소비한 블록에 묶지만, 기초 시장을 조작 불가능하게 만들지는 않습니다. 상관된 신호로 움직이는 에이전트 집단은 기초가 함께 움직일 수 있는 또 하나의 경로입니다. 오라클이 보장하는 것과 보장하지 않는 것을 보십시오. 에이전트의 자기 평가는 증거가 아닙니다. 거래의 피드백은 코드의 그것과 달리 잡음이 많고 비정상적입니다 — 컴파일러는 틀렸다고 알려 주지만, 수익이 난 한 주가 옳았다고 알려 주지는 않습니다. 장소가 에이전트를 위해 만드는 무엇이든, 에이전트 자신의 성과 진술을 측정이 아니라 적대적 입력으로 다뤄야 합니다. 직접 검증하기의 점검들이 보고될 수 있는 것이 아니라 다시 계산될 수 있는 것을 축으로 짜인 이유 중 하나가 이것입니다.다음으로 읽을 문서
AI 트레이딩: 지금과 다음
네 단계, 그리고 바뀌어야 하는 것이 계정인 이유.
직접 검증하기
에이전트의 평가를 주장 이상의 것으로 만드는 점검들.
신뢰 가정
확인할 수 있는 것을 확인한 뒤에 남는 것.
다음 단계
에이전트 런타임과 인가 조건의 상태.