지연 실행은 매우 강력합니다. 왜냐하면 실행과 컨센서스를 병렬로 수행하여 실행의 시간 예산을 대폭 확장시킬 수 있기 때문입니다.
가능한 반론은: 이제 컨센서스 노드들은 상태의 최신 정보를 갖고 있지 않기 때문에, 그들이 실수로 가스를 모두 소비한 계정의 거래를 포함하는 것을 어떻게 방지할 수 있을까요? 이는 Denial-of-Service (서비스 거부) 벡터를 만들어낼 수 있습니다.
이를 방어하기 위해 Monad는 거래가 네트워크를 통해 전달되기 위한 비용인 "운송 비용"을 도입하고, 각 계정에 대한 증거금 잔고를 유지하며, 증거금 잔고에 대한 운송 비용을 차감합니다.
Monad에서는 블록에서 거래를 네트워크를 통해 전송하는 데 비용이 발생합니다("운송 비용"). 이는 실행 비용과 별도의 비용입니다.
운송 비용은 스팸 방지를 위해 필요합니다. 이 비용은 최소이지만 네트워크 자원을 사용하는 비용을 반영합니다.
컨센서스에 포함되고 (운송에 대한 비용이 청구되어) 지정된 가스 한도에 비해 충분하지 않은 실행 예산을 가진 트랜잭션이 실행될 수 있습니다. 이 경우 실행 시간에 트랜잭션이 실패하지만 실패 지점까지 가스가 청구됩니다. 이는 이더리움과 다를 바가 없습니다. 계정에 충분한 이더가 없이 제출된 트랜잭션은 이더를 소모하고 실패합니다. 실패 지점까지 가스를 청구하는 것은 실행 DOS 공격을 방지하기 위해 필요합니다.
각 주소에 대해 노드는 두 가지 잔고를 유지합니다:
“운송 비용”은 트랜잭션이 블록에 포함될 때 (컨센서스) 준비금 잔고에 부과됩니다. 실행 시간에 수행 잔고에서 공제되고 (이중 청구), D블록 (10초)의 지연 기간이 지난 후에 준비금 잔고로 환불됩니다.
준비금은 사실상 "in-flight (인플라이트)" 주문의 예산입니다. 이는 지불된 트랜잭션만이 블록에 포함되도록 보장하기 위한 것입니다. 준비금 잔고는 실시간으로 감소한다고 생각할 수 있습니다(즉, 컨센서스가 발생하는 동안) 노드의 전체 상태 보기는 지연되어 있지만 준비금 잔고는 항상 최신 지출을 반영합니다.