사용자가 온체인 작업을 다른 사람에게 맡기려면 누가 실행할 수 있는지 찾고, 비용과 조건을 비교해야 함. 실행자를 한 명씩 직접 찾는다면 인텐트 방식의 편의성이 줄어들 수밖에 없음.

DAPPOS 실행망에서는 사용자가 매처에게 인텐트를 전달하면, 매처가 연결된 여러 서비스 제공자의 실행 견적을 받아 사용자에게 보여줍니다. 사용자가 조건에 맞는 견적을 고르면 인텐트 거래가 확정되고 실행 단계로 넘어감.

DAPPOS와 통합된 디앱에서는 Intent Task Framework가 사용자의 행동을 인텐트 형태로 자동 구성하고, 같은 화면 안에서 여러 제공자의 조건을 비교할 수 있도록 설계됐습니다. 인텐트 생성과 실행자 탐색을 분리하지 않고 하나의 흐름으로 묶는 것이 매처의 역할임.

서비스 제공자가 원하는 만큼 작업을 받은 뒤 실패해도 책임질 자산이 없다면 담보 구조의 의미가 약해짐. 맡은 작업 규모와 실제 책임 능력이 연결돼야 함.

DAPPOS 공식 문서에 따르면 서비스 제공자는 실행망에서 작업을 맡기 전에 담보를 스테이킹해야 합니다. 동시에 맡을 수 있는 인텐트의 총가치는 담보의 일정 비율을 넘을 수 없도록 제한됩니다.

매처는 실행 검증과 견적 매칭을 함께 담당하기 때문에 일반 검증자보다 더 많은 자산을 스테이킹하도록 설계됐습니다. 역할과 권한이 커질수록 책임 자산도 늘어나는 구조임.

즉 담보는 실패 후 벌금으로만 쓰이는 게 아님. 서비스 제공자가 현재 얼마나 많은 작업을 책임질 수 있는지 정하는 실행 용량으로도 작동함.

서비스 제공자의 담보가 맡은 작업 전체를 계속 묶고 있다면 새로운 인텐트를 받을 수 없음. 완료된 작업과 진행 중인 작업을 구분해 실행 용량을 갱신해야 함.

DAPPOS에서는 작업이 성공했고 누구도 결과에 챌린지를 제기하지 않으면 해당 작업의 가치가 서비스 제공자에게 해제됩니다. 동시에 제공자가 현재 책임지고 있는 인텐트 총가치가 줄어들어 새로운 작업을 받을 수 있게 됨.

따라서 담보는 한 번 예치하고 끝나는 정적인 보증금이 아님. 진행 중인 작업을 맡음→성공 검증→작업 가치 해제→새 작업 수용으로 반복되는 실행 자원임.

검증 결과가 서비스 제공자의 다음 수주 능력까지 바꾼다는 점이 아홉 번째 기술적 특징임.

사용자가 온체인 작업을 다른 사람에게 맡기려면 누가 실행할 수 있는지 찾고, 비용과 조건을 비교해야 함. 실행자를 한 명씩 직접 찾는다면 인텐트 방식의 편의성이 줄어들 수밖에 없음.

DAPPOS 실행망에서는 사용자가 매처에게 인텐트를 전달하면, 매처가 연결된 여러 서비스 제공자의 실행 견적을 받아 사용자에게 보여줍니다. 사용자가 조건에 맞는 견적을 고르면 인텐트 거래가 확정되고 실행 단계로 넘어감.

DAPPOS와 통합된 디앱에서는 Intent Task Framework가 사용자의 행동을 인텐트 형태로 자동 구성하고, 같은 화면 안에서 여러 제공자의 조건을 비교할 수 있도록 설계됐습니다.

인텐트 생성과 실행자 탐색을 분리하지 않고 하나의 흐름으로 묶는 것이 매처의 역할임.

서비스 제공자가 원하는 만큼 작업을 받은 뒤 실패해도 책임질 자산이 없다면 담보 구조의 의미가 약해짐. 맡은 작업 규모와 실제 책임 능력이 연결돼야 함.

DAPPOS 공식 문서에 따르면 서비스 제공자는 실행망에서 작업을 맡기 전에 담보를 스테이킹해야 합니다. 동시에 맡을 수 있는 인텐트의 총가치는 담보의 일정 비율을 넘을 수 없도록 제한됩니다.

매처는 실행 검증과 견적 매칭을 함께 담당하기 때문에 일반 검증자보다 더 많은 자산을 스테이킹하도록 설계됐습니다. 역할과 권한이 커질수록 책임 자산도 늘어나는 구조임.

즉 담보는 실패 후 벌금으로만 쓰이는 게 아님. 서비스 제공자가 현재 얼마나 많은 작업을 책임질 수 있는지 정하는 실행 용량으로도 작동함.

Intent를 처리하는 Service Provider에게 실행 방법까지 하나로 강제하면 시스템의 선택지가 줄어들 수 있음.

DAPPOS의 Intent Execution Network는 Service Provider가 Intent를 어떤 구체적인 방식으로 완수했는지는 중요하게 다루지 않고, 약속된 결과가 성공했는지를 중심으로 검증​합니다.

이게 중요한 이유는 실행과 검증을 서로 다른 문제로 볼 수 있기 때문임.

Execution
→ 결과를 만드는 가장 좋은 방법을 찾음

Verification
→ 약속된 결과가 실제로 나왔는지 확인함

Service Provider는 다양한 실행 방법을 선택할 수 있고,

Validator Network는 결과 조건을 중심으로 판단함.

실행 경로는 유연하게 두면서 결과에 대한 책임은 유지하는 구조라고 볼 수 있음.

Service Provider는 무한정 많은 Intent Task를 동시에 맡을 수 있는 구조가 아님.

DAPPOS에서는 Service Provider가 처리 중인 Task의 총가치가 담보와 연동되며, Task가 성공적으로 완료되고 검증되면 해당 Task Value가 현재 책임량에서 빠져 새로운 Task를 받을 수 있는 여지가 생깁니다.

Execution Workflow에서도 성공에 대한 Challenge가 발생하지 않으면 Service Provider에 대응되는 Task Value가 release되는 것으로 설명됩니다.

즉 검증은 과거 작업을 확인하는 절차만이 아님.

Task 수락
↓
Liability 사용
↓
Execution
↓
Verification
↓
Liability Release
↓
새 Task 수행 가능

이라는 하나의 Capacity Cycle을 구성함.

결과 검증이 네트워크의 실행 용량을 다시 순환시키는 역할까지 하는 것임.

Intent 시스템에서는 사용자가 직접 모든 단계를 실행하지 않음.

Service Provider가 사용자 대신 복잡한 실행 경로를 처리할 수 있음.

그렇다면 중요한 문제가 생김.

Service Provider가 필요한 작업을 어떻게 효율적으로 실행할 수 있게 할 것인가.

DAPPOS는 Unified Account를 Intent Execution과 본질적으로 호환되도록 설계해 Service Provider authorization을 원활하게 하는 방향이라고 설명합니다.

즉 계정 시스템과 실행 네트워크가 따로 놀면 안 됨.

Account
→ 자산 관리

Intent
→ 목표 정의

Service Provider
→ 실제 실행

이 세 가지가 연결돼야 함.

Intent 기반 Web3에서 Account Architecture가 중요한 이유가 바로 이 부분임.