수익형 자산으로 다른 디앱을 사용하려면 보통 사용자가 먼저 원래 자산으로 상환하고, 필요한 체인으로 옮긴 뒤 다시 거래해야 할 수 있음.

DAPPOS 문서에서는 사용자가 Intent Asset을 특정 상황에서 직접 사용하려 할 때, 해당 Intent Asset을 Execution Network의 입력값으로 제공하고 정산 작업을 서비스 제공자에게 맡기는 구조를 설명합니다. 실제 온체인 전환과 중간 작업의 복잡성은 제공자가 처리함.

따라서 사용자 입장에서는 수익 자산 상환→브리지→새 디앱 사용을 하나씩 수행하기보다 “이 자산으로 이 결과를 원함”이라는 작업으로 묶는 방식임.

Service Provider가 작업을 수행했는데 완료 보고를 하지 않는 상황도 생각할 수 있음.

그렇다고 사용자의 Intent가 무기한 대기 상태에 빠지면 안 됨.

DAPPOS의 실행 흐름에서는 Service Provider가 직접 완료를 보고하지 않을 경우 Intent에 지정된 시간이 지난 뒤 Execution Validator가 성공 여부를 검증할 수 있도록 설계돼 있습니다.

즉 상태 전환이 Service Provider 한쪽에만 의존하지 않음.

Provider 완료 보고
또는
시간 조건 이후 Validator 검증

이라는 두 경로가 있는 것임.

탈중앙 실행 시스템에서는 이런 구조가 중요함.

작업을 맡은 한 참여자가 응답하지 않는다고 해서 전체 settlement까지 멈추지 않게 하는 장치이기 때문임.

Service Provider가 작업을 수행했는데 완료 보고를 하지 않는 상황도 생각할 수 있음.

그렇다고 사용자의 Intent가 무기한 대기 상태에 빠지면 안 됨.

DAPPOS의 실행 흐름에서는 Service Provider가 직접 완료를 보고하지 않을 경우 Intent에 지정된 시간이 지난 뒤 Execution Validator가 성공 여부를 검증할 수 있도록 설계돼 있습니다.

즉 상태 전환이 Service Provider 한쪽에만 의존하지 않음.

Provider 완료 보고
또는
시간 조건 이후 Validator 검증

이라는 두 경로가 있는 것임.

탈중앙 실행 시스템에서는 이런 구조가 중요함.

작업을 맡은 한 참여자가 응답하지 않는다고 해서 전체 settlement까지 멈추지 않게 하는 장치이기 때문임.