Challenge를 누구나 아무 비용 없이 계속 걸 수 있다면 또 다른 공격 방법이 생길 수 있음.

정상적인 실행에도 계속 이의를 제기해서 settlement를 방해할 수 있기 때문임.

DAPPOS에서는 Challenge 이후 Validator Consensus가 실제로 Intent가 성공했다고 판정하면 잘못 Challenge한 참여자가 penalized되는 구조를 사용합니다.

반대로 실제 실패를 찾아냈다면 Challenger가 보상을 받음.

정리하면

실제 실패 + 올바른 Challenge
→ 보상

정상 실행 + 잘못된 Challenge
→ 패널티

임.

이런 양방향 인센티브가 필요한 이유는 단순함.

Service Provider만 정직하게 행동해야 하는 게 아니라 검증자 역시 자신의 판단에 책임을 져야 하기 때문임.

이번 흐름을 연결하면 DAPPOS의 Intent Execution 검증 방식이 조금 더 명확해짐.

Intent Deal
↓
Service Provider Execution
↓
Completion Report
↓
Validator Verification
↓
문제 발견 시 Challenge
↓
DPoS Voting
↓
Consensus
↓
성공이면 Settlement
또는
실패면 Compensation

그리고 잘못된 Challenge에도 패널티가 존재함.

여기서 중요한 건 Service Provider를 무조건 믿는 것도 아니고, 모든 작업을 네트워크가 처음부터 직접 수행하는 것도 아니라는 점임.

실행은 외부 참여자에게 맡기되 결과에 반박할 수 있는 검증 경로와 경제적 책임을 붙이는 것.

이 방식 덕분에 Service Provider는 다양한 방법으로 Intent를 실행할 수 있으면서도, 실패 여부에 대한 책임 구조는 유지할 수 있음.

DAPPOS의 OM
S를 단순한 담보 시스템보다 Execution Freedom과 Verifiable Outcome을 연결하는 프로토콜 설계로 봐야 하는 이유임.