작업을 수행한 서비스 제공자가 자기 결과를 최종 판정한다면 실패를 숨기거나 판단 기준을 유리하게 해석할 수 있음. 실행과 검증을 나눌 필요가 있는 이유임.

DAPPOS에서는 서비스 제공자가 작업 완료를 먼저 보고할 수 있습니다. 제공자가 보고하지 않더라도 인텐트에 지정된 시간이 지나면 Execution Validator가 실제로 결과가 만들어졌는지 확인합니다.

검증자가 실패를 발견하면 실행망에 챌린지를 제출할 수 있음. 즉 서비스 제공자는 실행을 맡고, 검증자는 약속된 결과가 충족됐는지를 따로 확인하는 구조임.

실행자가 결과를 제출하더라도 독립된 검증 절차가 남아 있다는 점이 일곱 번째 신뢰 장치임.

검증자 한 명이 단독으로 실패를 결정할 수 있다면 잘못된 판정이나 악의적인 챌린지가 새로운 위험이 될 수 있음. 검증자에게도 책임과 합의 절차가 필요함.

DAPPOS 공식 워크플로에 따르면 실패 챌린지가 발생하면 실행 검증자들이 DPoS 방식으로 투표해 결과를 합의합니다. 합의 결과 작업이 실패했다면 서비스 제공자의 담보로 사용자를 보상하고 챌린저에게 보상을 지급함.

반대로 실행이 정상적으로 완료됐다고 판정되면 잘못된 챌린지를 제출한 검증자가 불이익을 받습니다. 검증자도 담보를 맡기며, 늦거나 잘못된 판정을 제출하면 페널티를 받을 수 있음.

실행자뿐 아니라 판정을 내리는 검증자에게도 경제적 책임을 부여한 것이 여덟 번째 기술적 특징임.

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

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

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

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

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

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

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

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

Execution Validator의 역할은 결과를 구경하고 기록하는 것만이 아님.

DAPPOS 공식 실행 흐름에서는 Intent Task가 실패했다고 판단되면 Execution Validator가 네트워크에 Challenge를 제기할 수 있습니다.

여기서 Challenge는 중요한 상태 변화임.

한 Validator가

“이 실행은 실패한 것 같다”

라고 판단했다고 즉시 Service Provider가 처벌되는 것은 아님.

Challenge가 발생하면 그다음에는 네트워크 차원의 합의 과정으로 넘어감.

즉

실패 의심
→
Challenge
→
Network Consensus

라는 구조임.

개별 감시자가 문제를 발견할 수 있게 하되 최종 판정까지 혼자 내리지는 못하게 만드는 방식임.

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

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

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

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

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

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

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

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

Execution Validator의 역할은 결과를 구경하고 기록하는 것만이 아님.

DAPPOS 공식 실행 흐름에서는 Intent Task가 실패했다고 판단되면 Execution Validator가 네트워크에 Challenge를 제기할 수 있습니다.

여기서 Challenge는 중요한 상태 변화임.

한 Validator가

“이 실행은 실패한 것 같다”

라고 판단했다고 즉시 Service Provider가 처벌되는 것은 아님.

Challenge가 발생하면 그다음에는 네트워크 차원의 합의 과정으로 넘어감.

즉

실패 의심
→
Challenge
→
Network Consensus

라는 구조임.

개별 감시자가 문제를 발견할 수 있게 하되 최종 판정까지 혼자 내리지는 못하게 만드는 방식임.