[ERC8350] AI 에이전트의 저장 데이터를 공개하지 않고 업데이트 이력을 확인하는 메커니즘

처음 뵙겠습니다.

『DApps 개발 입문』이라는 책이나 여러 기사를 쓰고 있는 karude ne입니다.

아래에서도 정보를 발신하고 있으니, 흥미로운 글이 있다면 꼭 읽어보세요!

AI 에이전트가 사용자의 선호나 과거 조작을 학습할 때, 그 내용은 보통 사업자의 비공개 데이터베이스에 저장됩니다.

하지만 사업자를 이전하거나 나중에 감사하는 상황에서는, 현재의 기억이 어떤 업데이트를 거쳐 만들어졌는지 제3자가 확인할 수 없습니다.

ERC8350은 메모리 내부 내용을 Ethereum에 올리지 않고, 허가된 업데이트가 끊김 없이 일렬로 연결되었음을 검증하기 위한 표준입니다.

표준이 정하는 데이터, 권한, 서명, 상태 전이를 그리고 공식 참고 구현의 처리를 코드와 함께 설명하겠습니다.

여행을 예약하는 AI 에이전트가 사용자로부터 "창가 좌석을 우선한다"고 배운 상황을 가정해 보겠습니다.

사업자는 그 선호를 비공개 데이터베이스에 저장할 수 있습니다.

다만, 저장 내용의 해시(hash)만을 Ethereum에 기록하더라도, 그 값이 어떤 이력의 연속인지, 누가 업데이트를 허가했는지, 중간 업데이트가 빠지지 않았는지는 알 수 없습니다.

ERC8350은 하나의 메모리 이력을 나타내는 공간을 만들고, 업데이트마다 현재 위치, 비공개 데이터를 나타내는 값, 해석 방법을 나타내는 값, 저장소를 나타내는 값을 정리합니다.

업데이트를 허가하는 계정의 승인과 직전 상태로부터 단 하나만 진행되었음을 레지스트리(registry)가 확인하고 최신 지점을 업데이트합니다.

원시 메모리, 암호 키, 비공개 저장소는 레지스트리에 전달하지 않습니다.

이 메커니즘을 통해 감사자는 공개된 증거로부터 "이 업데이트가 등록된 권한자에게 승인되었고, 알려진 이력 바로 다음에 추가되었다"는 것을 확인할 수 있습니다.

반면에, 기록된 내용이 진실인지, AI가 실제로 그 기억을 사용했는지, 비공개 데이터를 현재도 가져올 수 있는지는 증명하지 않습니다.

각 메모리 이력에서는 빈 head의 순번(連番)이 0이고, 첫 번째 transition의 순번은 1입니다.

게다가 직전까지의 이력을 모은 값을 가집니다.

이 일렬로 된 에이전트 메모리 이력을 표준에서는 Memory Space라고 부릅니다.

새로운 업데이트는 저장 중인 순번보다 정확히 1 크고, 직전 값이 현재 값과 일치하는 경우에만 수용됩니다.

이 조건으로 인해 중간을 건너뛴 업데이트나 오래된 지점으로 돌아가는 업데이트는 거부됩니다.

분기 또는 여러 업데이트를 나중에 통합하는 메커니즘은 표준의 대상이 아닙니다.

레지스트리에 두는 것은 원시 선호도나 대화가 아니라, 비밀 값으로부터 계산한 고정 길이의 commitment입니다.

commitment는 나중에 원 데이터와 비밀 값을 공개했을 때, 등록 시점과 같은 내용이었는지 대조하기 위한 값입니다.

업데이트 내용, 출처, 저장 장소는 각각 다른 commitment로 분리합니다.

이러한 분리로 인해, 예를 들어 업데이트 내용만 감사자에게 공개하고, 저장 장소는 숨길 수 있습니다.

먼저 관리자가 메모리 공간을 등록하고, 일상적인 업데이트를 승인할 계정을 지정합니다.

AI 에이전트 운영 측은 비공개 데이터에서 commitment를 만들고, 현재 이력 위치와 함께 서명을 받습니다.

송신자는 서명된 업데이트를 레지스트리에 제출하고, 레지스트리는 권한과 연속성을 확인하여 최신 지점을 진행합니다.

감사자는 이벤트와 현재 값을 읽어 같은 계산을 재실행할 수 있습니다.

필요한 경우에만 운영 측에서 공개한 비공개 데이터를 commitment와 대조합니다.

AI 에이전트의 메모리를 다른 사업자에게 이전할 때, 이전받는 곳은 전달된 데이터가 최신인지, 중간에 교체되지 않았는지 스스로 판단할 수 없습니다.

단일 해시(hash)를 공개하는 방법으로는, 그 해시를 누가 승인했는지, 어떤 상태로 진행되었는지, 다른 구현에서도 같은 식별값이 되는지 알 수 없습니다.

반대로, 원시 프롬프트, 사용자 선호도, 임베딩 표현, 운영 방침을 Ethereum에 쓰면, 내용이 공개되고 저장 비용도 늘어납니다.

ERC8350은 공개하는 값을 고정 길이의 진술(申告)과 서명으로 한정하고, 내용을 보관 및 해석하는 메커니즘을 오프체인에 남깁니다.

단순한 해시, 일렬의 레지스트리, 분기 가능한 이력을 비교하면 용도의 차이가 보입니다.

프롬프트나 사용자 선호도에는 개인정보가 포함될 가능성이 있습니다.

저장소 URI에는 사업자명, tenant ID, access token 등이 포함되는 경우도 있습니다.

ERC8350은 원시 데이터를 비공개로 보관하고, 각각을 나타내는 commitment만을 서명 대상에 포함합니다.

이를 통해 전송을 대행하는 relayer도 서명된 저장소나 업데이트 내용을 다른 값으로 대체할 수 없습니다.

동일한 업데이트에서 서로 다른 식별자가 생성되면, 감사자(auditor)와 registry가 동일한 이력을 참조할 수 없게 됩니다.

ERC8350은 타입 문자열(type string), 필드 순서(field order), 해시 함수(hash function), 서명 도메인(signature domain)을 고정합니다.

공식 테스트 벡터에는 입력, commitment, 타입 해시, transition ID, 업데이트 후 state root, 서명 digest가 게재되어 있습니다.

구현자는 자신의 계산 결과를 공식 값과 비교하여 인코딩이나 필드 순서의 차이를 감지할 수 있습니다.

업데이트를 한 건씩 확정하고 나중에 순서와 승인자를 검증하고 싶을 때 ERC8350이 적합합니다.

단일 파일 hash만으로 충분한 용도나, 여러 브랜치를 병렬로 merge하는 용도에서는 더 단순한 기록 또는 다른 이력 모델을 선택합니다.

규격은 어떤 AI 모델, 벡터 DB, 검색 방식을 사용할지 정하지 않습니다.

메모리 내용의 진실성이나 가용성까지 필요한 경우에는 데이터 가용성(data availability), provenance, proof 메커니즘을 별도로 조합해야 합니다.

ERC8350은 메모리 이력을 식별하는 값, 업데이트 신고(update declaration), 이력을 연결하는 계산, 권한(authority), 서명과 인터페이스를 정의합니다.

2026년 10월 15일 기준으로 Draft 상태입니다.

MemorySpace는 하나의 메모리 이력을 분리하는 네임스페이스입니다.

최초의 controller와 32-byte salt로부터 다음 수식으로 spaceId를 만듭니다.

MEMORY_SPACE_TYPE = "MemorySpace(address initialController,bytes32 salt)"
spaceId = keccak256(abi.encode(
...

controller를 계산에 포함시키기 때문에, 제삼자가 동일한 salt만 사용하여 먼저 공간을 등록하는 것을 방지합니다.

salt는 등록 함수의 calldata로 전달되므로, 등록 후에도 비밀로 유지할 값은 아닙니다.

ExperienceDelta는 한 번의 메모리 업데이트를 고정 폭으로 나타내는 신고(declaration)입니다.

운영 측에서 생성하고, authorizer가 서명하며, registry와 감사자가 동일한 필드를 읽습니다.

struct ExperienceDelta {
bytes32 spaceId;
uint64 sequence;
...

| 필드 | 만드는 값과 의미 | 조건 |
|---|---|
spaceId | 업데이트할 메모리 공간을 지정합니다. | 등록된 공간이어야 합니다. |
sequence | 해당 공간에서 몇 번째 업데이트인지를 나타냅니다. | 처음은 1이며, 현재 값보다 1 크게 만듭니다. |
prevStateRoot | 업데이트 직전까지의 이력을 나타냅니다. | 처음은 zero이며, 이후는 현재 root와 일치시킵니다. |
deltaCommitment | 비공개 업데이트 내용 또는 암호문을 나타냅니다. | zero는 사용할 수 없습니다. |
provenanceCommitment | 입력이나 추론 attestation 등, 업데이트의 출처를 나타냅니다. | 생략 시 zero입니다. |
profileId | commitment 생성 방식과 비공개 데이터 해석 방법을 구분합니다. | zero는 사용할 수 없습니다. |
locatorCommitment | 비공개 저장소를 나타냅니다. | 생략 시 zero입니다. 원시 URI를 포함하지 않습니다. |

원시 메모리, commitment용 salt, 암호 키, raw locator는 포함하지 않습니다.

누가 작성했는지에 대한 자기 신고나 시간도 필드에 넣지 않으며, 승인자는 서명으로, 관측 시각은 체인 측의 기록으로 처리합니다.

Transition ID는 한 번의 ExperienceDelta를 구현자들 사이에서 동일한 값으로 지칭하는 식별자입니다.

JSON 등으로 변환하지 않고, 정확한 타입 문자열과 7개의 필드를 abi.encode하여 계산합니다.

공식 테스트 벡터의 1건에서는, transitionId는 0xdd00dd6e...91e7f4e5가 됩니다.

transitionId 자체는 체인에 의존하지 않습니다.

반면, 서명을 검증하는 digest에는 체인과 레지스트리가 포함되기 때문에, 이 둘을 같은 값으로 취급하지 않습니다.

State Root는 현재까지 수락된 업데이트의 순서를 나타내는 누적값입니다.

직전 root와 이번 transitionId로부터 업데이트 후 값을 계산합니다.

MEMORY_STATE_TYPE = "MemoryState(bytes32 prevStateRoot,bytes32 transitionId)"
nextStateRoot = keccak256(abi.encode(
...

성공 시에는 transitionId, nextStateRoot, sequence를 같은 트랜잭션으로 저장합니다.

어느 것의 확인에서 실패하면 전체 트랜잭션이 revert되고, head는 변하지 않습니다.

하나의 공간(space)에는 관리 작업을 수행하는 controller와 일상적인 메모리 업데이트를 허용하는 authorizer가 있습니다.

권한 업데이트에서는 현재의 configNonce보다 1 큰 값을 서명 대상에 포함합니다.

오래된 권한 설정의 서명을 재사용하더라도, nonce가 현재 값과 일치하지 않기 때문에 수락되지 않습니다.

공간 등록, 권한 업데이트, 상태 전이의 서명에는 EIP712의 domain을 사용합니다.

EIP712는 지갑(wallet)과 컨트랙트가 같은 형식화된 데이터(typed data)를 해시하는 방식입니다.

서명 domain에는 chain ID와 registry address를 포함합니다.

이를 통해 동일한 구조에 대한 서명을 다른 체인이나 다른 레지스트리에서 재사용할 수 없습니다.

EIP712에 대해서는 다음 기사를 참고해 주십시오.

서명 대상은 keccak256(0x1901 || domainSeparator || structHash)입니다.

독립적으로 검증 가능한 transition 참조에는 체인, 레지스트리 주소, spaceId, transitionId를 포함합니다.

이력이 일렬로 될 것이라는 보장은 저장된 데이터가 아니라, 수락 조건을 실행하는 코드에 있습니다.

구현을 교체할 수 있는 proxy는 나중에 순번이나 서명을 제외한 코드로 변경될 수 있습니다.

준수 레지스트리(compliant registry)는 선형성(linearity), root chaining, 서명 검증을 수행하는 로직을 교체할 수 있는 업그레이드 메커니즘의 배후에 놓일 수 없습니다.

공식 vector와 동일한 해시를 계산할 수 있다는 것과, deployment가 미래에도 같은 승인 조건을 지킨다는 것은 별개의 확인 사항입니다.

대표적인 proxy는 표준화된 storage slot을 읽습니다.

slot 확인과 공개 소스(public source)를 결합하여 강제 로직(enforced logic)을 교체할 권한이 남아 있는지 조사합니다.

deployment 감사에서는 공개 소스와 bytecode, owner, admin, initializer, upgrade 함수, 임의의 delegatecall, ERC1967 slot, 독자적인 proxy 메커니즘을 확인합니다.

ERC1967의 표준 slot이 비어 있어도, 독자적인 업그레이드 경로가 없다는 증거가 되지는 않습니다.

ERC1967에 대해서는 다음 기사를 참고해 주세요.

규격의 interface에는 하나의 구조체(struct), 세 개의 이벤트(event), 여섯 개의 필수 함수(function)가 있습니다.

참고 구현은 감사나 통합을 돕는 임의의 읽기/계산 함수도 추가하고 있습니다.

struct ExperienceDelta {
bytes32 spaceId;
uint64 sequence;
...

registry에 제출하는 한 번의 업데이트 신고입니다.

field 순서는 v1의 wire format 일부이며, 재배열하면 transitionId가 바뀝니다.

필드(Field)

core registry는 profileId의 도출 방법, 충돌 회피, 등록 장소, 거버넌스(governance), profile 정의 배포 방법을 정하지 않습니다.

검증자는 대응하는 profile 정의를 별도의 경로에서 가져와, 그 정의가 나타내는 부호화(encoding)와 검증 규칙으로 private witness를 확인합니다.

event SpaceRegistered(
bytes32 indexed spaceId,
address indexed controller,
...

새로운 메모리 공간의 등록 완료를 알립니다.

등록 직후의 transitionId, stateRoot, sequence, configNonce는 zero이지만, 이 이벤트에는 포함되지 않습니다.

필드(Field)

이 이벤트만으로는 spaceId의 도출에 사용된 salt나 controller의 승인을 복원할 수 없습니다.

독립 감사에서는 등록 transaction의 calldata와 송신자 또는 서명도 확인합니다.

event SpaceAuthorizationUpdated(
bytes32 indexed spaceId,
address indexed controller,
...

controller 또는 authorizer를 업데이트한 결과를 알립니다.

두 개의 address와 configNonce는 업데이트 후의 값입니다.

감사자는 등록부터 이벤트를 순서대로 추적하며, 각 상태 전이가 발생했을 시점의 authorizer를 복원합니다.

필드(Field)

상태 전이(State Transition)가 수락되고 head가 업데이트되었음을 알립니다.

감사자(Auditor)는 직전 상태와 업데이트 후의 root, commitment, profile, 승인 시점의 authorizer를 가져올 수 있습니다.

이벤트에는 서명된 bytes는 포함되지 않습니다.

비어있지 않은 서명의 검증에는 transaction의 calldata가 필요하며, 빈 서명의 검증에는 transaction의 sender(전송자)를 확인합니다.

필드

events TransitionCommitted(
bytes32 indexed spaceId,
bytes32 indexed transitionId,
...

첫 번째 controller와 salt로부터 spaceId를 계산합니다.

등록 전에 client와 registry가 동일한 식별자를 얻기 위한 함수입니다.

• controller 확인: initialController가 zero address가 아님을 확인합니다. -
  식별자 계산: 타입 해시(type hash), controller, salt를 abi.encode하고 keccak256을 적용합니다.

인수

반환값

• 실행 조건: -
  상태를 변경하지 않는 pure 함수이므로, 임의의 caller가 실행할 수 있습니다. -
  initialController가 zero address인 경우 실패합니다.

function deriveSpaceId(address initialController, bytes32 salt)
external pure returns (bytes32 spaceId);

새로운 메모리 공간을 등록하고, 첫 번째 controller와 authorizer를 저장합니다.

relayer가 제출하는 경우, controller가 SpaceRegistration에 붙인 서명을 전달합니다.

서명 대상의 타입 문자열과 struct hash는 다음과 같습니다.

SpaceRegistration(bytes32 spaceId,address controller,address authorizer)

keccak256(abi.encode(
SPACE_REGISTRATION_TYPEHASH,
spaceId,
...

• 입력 확인: zero 값, 도출된 spaceId와의 일치, 미등록 상태임을 확인합니다. -
  controller의 승인 확인: controller 본인의 직접 호출 또는 서명으로부터 승인을 확인합니다.

• 초기 상태 저장: controller와 authorizer를 저장하고, head와 nonce를 zero로 초기화합니다.

• 등록 통지: SpaceRegistered 이벤트를 발행합니다.

인수

매개변수

발행 이벤트
성공 시 SpaceRegistered 이벤트를 발행합니다.

• 실행 조건 -
  지정된 공간이 미등록인 경우에 실행할 수 있습니다.

• controller와 authorizer는 zero address가 아닌 값을 지정해야 합니다.

• 도출된 spaceId와 매개변수 값들이 일치해야 합니다. - controller의 승인을 유효하게 합니다.

• 공백 서명(empty signature)에 의한 본인 직접 호출을 수용하는 처리는 규격상 MAY이며, 공식 참고 구현은 msg.sender == controller 인 경우에만 수용합니다.

function updateSpaceAuthorization(
bytes32 spaceId,
address newController,
...

현재 controller의 승인을 확인하고, controller와 authorizer를 같은 트랜잭션에서 교체합니다.
한쪽만 유지하는 경우에는 해당 주소를 새로운 값에도 지정합니다.

서명 대상의 타입 문자열과 struct hash는 다음과 같습니다.

SpaceAuthorization(bytes32 spaceId,address newController,address newAuthorizer,uint64 nonce)

keccak256(abi.encode(
SPACE_AUTHORIZATION_TYPEHASH,
spaceId,
...)

• 공간 읽기 등록된 SpaceRecord와 현재 configNonce를 읽습니다. - 업데이트 내용 해시화 두 개의 새로운 주소와 configNonce + 1을 서명 대상으로 넣습니다. - controller의 승인 확인 현재 controller 본인에 의한 직접 호출 또는 서명을 검증합니다.

• 권한 일괄 업데이트 두 개의 주소와 nonce를 저장하고, 이벤트를 발행합니다.

매개변수

발행 이벤트
성공 시 SpaceAuthorizationUpdated 이벤트를 발행합니다.

• 실행 조건 -
  공간이 등록된 경우에 실행할 수 있습니다.

• 두 개의 새로운 주소는 zero가 아닌 값을 지정해야 합니다.

• 현재 controller의 승인을 유효하게 합니다.

• 공백 서명(empty signature)에 의한 본인 직접 호출을 수용하는 처리는 규격상 MAY이며, 공식 참고 구현은 msg.sender 가 현재 controller와 일치하는 경우에만 수용합니다. - 조건을 충족하지 못하는 트랜잭션은 revert하고, 두 개의 주소와 configNonce를 변경하지 않습니다.

function commitTransition(
ExperienceDelta calldata delta,
bytes calldata authorizerSignature
...)

등록된 공간의 헤드를 정확히 하나 다음 상태로 진행합니다.
현재 authorizer의 서명을 확인한 후, 개별 transition과 최신 head를 저장합니다.

• 공간 및 필수 값 확인 등록된 공간, 비(非)zero의 deltaCommitment와 profileId를 확인합니다. - 이력 연결 확인 연속 번호가 현재 값보다 1 크고, prevStateRoot

현재값과 일치하는지 확인합니다. - 업데이트 및 서명 확인
transitionId를 계산하고, 중복 여부와 authorizer의 승인을 확인합니다. -
두 저장소를 업데이트개별 transition을 저장하고, 공간의 head, root, sequence를 업데이트합니다.

확정 결과 통지
TransitionCommitted 이벤트를 발행하고, 두 개의 계산값을 반환합니다.

인수 (Arguments)

반환값 (Returns)

발행 이벤트 (Emitted Event)

성공 시 TransitionCommitted 이벤트를 발행합니다.

실행 조건 (Execution Conditions) -
공간이 등록된 경우에 실행할 수 있습니다.

deltaCommitment와 profileId는 zero가 아닌 값을 지정해야 합니다. -
순번을 현재값보다 1 크게 하고,
prevStateRoot를 현재값과 일치시킵니다. -
현재 authorizer의 승인을 유효하게 합니다.

공백 서명에 의한 본인의 직접 호출을 수령하는 처리는 규격상 MAY이며, 공식 참고 구현은