기본적으로 베이킹을 위해 트랜잭션을 실행할 필요가 없습니다. 거래는 수수료를 지불 할 수 있는지 여부에 따라 유효하거나 유효하지 않습니다. 이 문제는 수수료 지불 능력이 다른 거래의 존재 여부에 따라 달라질 수 있다는 사실에서 비롯됩니다.

이를 해결하기 위해, 우리는 다음과 같은 제약으로 제빵사를 의도적으로 제한합니다. 제빵사는 수수료 지불 능력에 대한 mempool의 tz [123] 계정 잔액 증가를 계산하지 않을 것입니다. 오히려 우리는 tz [123]의 잔액에서 수수료가 공제되는 단순화 된 가상 컨텍스트를 생성합니다. 이는 mempool이 수수료가 높은 tz [123] 계정의 거래를 무시할 수 있음을 의미 할 수 있습니다. 해당 계정은 이미 매력적이지 않은 일련의 거래를 통해 고갈 되었기 때문입니다.

tz [123] 주소 소유자입니다. 제 3자가 거래를 무시할 수있는 것과는 다릅니다.
이를 처리하는 올바른 방법은 적절한 유료 교체 메커니즘을 도입하는 것입니다. 이는 제 생각에는 합리적이지만 특히 높은 우선 순위는 아닙니다.
이 시스템에는 순서에 관계없이 mempool의 모든 하위 집합이 유효한 블록이라는 속성이 있습니다. 이것은 트랜잭션을 실행하지 않고도 알 수 있습니다. 물론 제빵사는 여전히 거래가 파싱되고 서명이 유효한지, 수수료를 지불 할 수 있는지 확인해야하지만 스마트 계약을 전혀 실행할 필요가 없습니다.

제빵사가 결코 고려하지 않을 잠재적으로 유효한 거래 세트가 있기 때문에 이것은 처음에는 약간 제한적으로 보일 수 있습니다. 그러나 이러한 세트가 중요한 이유에 대한 특별한 사용 사례 나 근거는 없습니다. 거래 수수료는 단일 블록을 기다리는 것이 주요 자본 잠금을 나타낼 정도로 비싸지 않습니다.

이제 워크 플로는 다음과 같습니다.

클라이언트가 트랜잭션을 보냅니다.
Mempool은 거래를받습니다
노드는 그것이 구문 분석되고, 올바르게 서명되었는지, 그리고 그것을 지불하는 tz [123] 주소가 수수료를 지불 할 수 있는지 확인합니다.
Baker는 mempool에서 가장 매력적인 트랜잭션을 잡고 블록으로 밀어 넣습니다 (다중 제약 조건 배낭 문제에 대한 휴리스틱 또는 의사 다항식 솔루션을 따름).
Baker는 블록을 게시합니다.
Baker는 자신의 블록이 (최소한 일시적으로) 체인의 헤드임을 확인하고 콘텐츠를 실행합니다.
여기에 필요할 수있는 다른 변경 사항에 대해서는 논의하지 않았습니다. 현재, 각 블록은 블록 실행 이후의 컨텍스트 해시에 커밋됩니다. 이것은 제빵사가 블록을 게시하기 전에 해시를 계산 한 다음 블록을 게시 할 수 있기 때문에 이론적으로 여전히 가능합니다. 체인의 HEAD가되었을 때 다시 실행할 필요가 없습니다. 그러나 블록이 블록 실행 전 (또는 동등하게 이전 블록 실행 후)처럼 컨텍스트의 해시에 커밋되도록하는 것이 더 간단 할 수 있습니다.

스마트 계약이 "소모"되고 거래 수수료를 지불 할 수있는 것을 방지해야하는 이유는 무엇입니까? 스마트 계약의 잔액은 거래의 부작용으로 줄어들 수있는 반면, tz [123] 잔액은 간단한 거래로만 줄일 수 있기 때문입니다. 스마트 컨트랙트가 mempool의 모든 트랜잭션을 실행하지 않고 수수료를 지불 할 수 있는지 확인하는 것은 불가능합니다.