[한국어 번역은 아래에 있습니다.]
This KIP-249 introduces the concept of “early deadline” to ensure the enough auction time for all transactions in a block. But, without proper detection rule, the malicious validators might not follow this early deadline to get the exclusive opportunity for profitable transaction. Since it’s not an easy problem, we’d like to hear the voice from community and find out the solutions.
In the highest level, we need to choose whether validating early deadline into consensus or not, and prepare initial ideas from our side. If you have any question/ideas/feedbacks, please feel free to leave a comment so gather more brain power!
1. Auction In Consensus
Goal: To prevent the modification of auction transactions (tx) or the addition of arbitrary auction transactions, thereby mitigating the risks posed by malicious proposers.
Out-of-Scope Issue:
While proposers are not strictly obligated to include auction transactions in a block, failing to do so would result in a loss of potential profit. This makes it unlikely for them to disregard this obligation.
Terminology:
- Prebuilt Block Template (PBT): A predefined list of transactions committed at an early deadline.
Method
- The proposer of Block N broadcasts the PBT to all CNs.
- The proposer of Block N+1 appends auction and lend transactions to the received PBT and proceeds with mining Block N+1.
- Verification process of Block N+1 in step by step
- Auction transaction verification
1. Verify the signature of the proposer of Block N+1.
2. Check whether the auctioneer signature field in the auction transaction contains the valid signature of the auctioneer.
- Lend transaction verification
1. Verify the signature of the proposer of Block N+1.
2. Confirm the presence of the two following transactions (approve, swap) after the lend transaction.
3. Ensure that transactions A (approve) and S (swap) are included in the PBT.
4. Validate compliance with KIP-245 (e.g., checking whether the to address of L, A, and S is a whitelisted ERC-20 contract).
Issues
- Auction Bypass Attack
- If the transaction
S was created by the proposer of Block N and the proposer of Block N+1 omits the auction transaction while appending a GA bundle (LAS) immediately after the target transaction hash, the logic above would still validate it. This allows the proposer to indirectly hijack the auction.
- However, for this attack to succeed, the proposers of Block N and Block N+1 must have aligned interests. If they do not, there is no incentive to ignore the auction transaction, making this attack path feasible only if at least two malicious proposers collaborate.
- Example**:**
- PBT =
[target_tx, S]
- Expected Scenario =
[target_tx, auction, LAS]
- Attack Scenario =
[target_tx, LAS] (Executing backrun via GA bundling without consuming a bid)
- Issues and Solutions of the PBT Approach
- Issue 1: Validation of the PBT propagated to CNs in every block.
- Solution 1: Ensure that the PBT signature matches the signature of the previous block’s proposer.
- Issue 2: Since the transaction list for the next block is pre-constructed by the previous block’s proposer, it could be manipulated. A malicious proposer could propose an invalid block that violates state rules or exclude transactions to not earn gas fees.
- Solution 2: In the PBT approach, the block proposer must create not only the current block but also the template for the next block. To ensure fairness, block rewards should be tightly coupled between consecutive blocks. Thus, the block reward mechanism should be modified as follows:
- Tightly Coupled Block Rewards
- Distribute the current block’s reward in a 50:50 ratio between the previous proposer and the current proposer.
1. Auction In Non-consensus
Goal: We need to detect the malicious actions of validators.
- The validators should follow the early deadline to ensure the auction window for all transactions.
- The auctioneer should process the auction results as protocol rule.
Basic Idea: The auctioneer keeps receiving the pending transactions from each validators already, so we can check if the each validators follow the early deadline with one more message: MSM. (Mining Start Message)
- MSM: Each validators will send the ordered hashes of all transactions in a block and a mining block number to the auctioneer right after the mining started:
{hashes, miningBlockNum}.
Then, the auctioneer will receive below two messages via websocket from each validators and it records message with the timestamp.
- Pending transactions: Similar to
eth_subscribe([“newPendingTransactions”], but share the full transaction to auctioneer.
- MSM: As soon as a validator starts the mining.
Please note that the auctioneer should have received all transactions in MSM previously since the transactions in MSM must come from pending transaction. So the expected timing would be:
tx -> Val1: Receives transactions and add it to pending pool.
Val1 -> auctioneer: Sends newly added pending transaction.
...
Val1 -> auctioneer: Sends MSM
For example, Validator#1 will send messages like below:
Val1 -> Auctioneer: [... {hashZ, N-1}], [A, B, C, D {hash{A, B, C}, N}], [E, F, G, {hash{D, E, F}, N+1}], [H, I, {hash{H, I}, N+2}], ...
Then, the auctioneer can expect the tx list of a block if Val#1 becomes the proposer. If the Val#1 becomes proposer at blockN+1, then the blockN+1 should contain {D, E, F} and the last transaction would be F.
As we checked before, the auctioneer has receiving time of all pending transactions and MSM. Using this, we can estimate the early deadline of proposer.
// In auctioneer's local time
Tx D: 00:40
Tx E: 00:63
Tx F: 00:85
<- Early deadline
Tx G: 00:93
MSM : 01:05 {D, E, F}
In the above timestamp, we can assume that the proposer sets the early deadline between F and G, at least 01:05 - 00:93 = 00:12. Since it is affected by network condition, we can assume that proposer doesn’t follow the rule if it occurs in very suspicious timing (there was very profitable arbitrage chances) or regularly. The standards will be set after discussion with ecosystem participants if needed.
And in transaction insertion perspective, a block might contain the transactions that auctioneer doesn’t receive from validator. We can separate this case in two:
- Insert non-reported txs before the last tx:
D, *G*, E, F
- If
G is bundle transactions or correctly broadcasted txs, there’s no problem.
- If
G is arbitrary transactions from proposer, it’s scope-out.
- Insert non-reported txs after the last tx:
D, E, F, *G*
- If
G is bundle transactions, there’s no problem.
- If
G is arbitrary transactions from proposer, we can 100% sure the proposer is malicious.
And in bundle process perspective, we can assume the validator is malicious if it doesn’t contain the auction result once the auctioneer sends it to the CN network.
- If auction result doesn’t pass the static validation: Can be detected off-chain
- If proposer claims it hasn’t received any bid result: We can suspect if other validators receive the bid result without issues.
Using this methods, we can find malicious actions of validators with minimum impact of CN client.
By leveraging this post-validation, we can detect/punish the malicious proposer accordingly. For example, we once introduced the rule to exclude validators from network temporary if do not participate in on-chain governance.
Note: We need to adjust the time record timing to after the insertion in node client.
Receive Insertion Mining
Tx1: ------------|------------|-----------------|------
R I Mining
Tx2: --------------|----|-----------------------|------
^ Early-deadline: Tx1 can't have enough auction time
So, the early deadline based on receipt will be passed, but it can't count the actual "insertion" where the auctioneer can start the auction.
[KR]
본 KIP-249는 모든 트랜잭션에 대하여 충분한 옥션 타임을 보장하기 위한 장치인 "early deadline"을 도입합니다. 하지만, 적절한 규칙없이는 악의적인 validator가 수익성있는 transaction에 대한 독점 기회를 가지기 위해 이러한 early deadline을 올바르게 따르지 않을 수 있습니다. 이를 해결하기 위해 저희는 생태계 참여자들의 의견을 함께 듣고자 합니다.
가장 상위 레벨에서, 저희는 early deadline과 관련된 규칙을 "컨센서스"단에서 다룰 것인지 여부를 결정하고, 이를 토대로 적절한 솔루션을 생각해볼 수 있고, 우선 고려될 수 있는 아이디어를 각각 하나씩 준비했습니다. 만약 해당 의견과 관련하여 질문/아이디어/피드백이나 새로운 아이디어가 있다면 꼭 함께 이야기해볼 수 있으면 좋겠습니다. 감사합니다.
1. Auction In Consensus
- 목표: 옥션 tx를 수정하거나 임의의(옥션) tx를 추가할 수 없도록하여 악의적인 프로포저의 위협을 제한합니다.
- 범주외의 문제: 옥션 tx를 블럭에 삽입해야하는 의무를 따르지 않을 수 있으나 이익을 버리는것과 동일하기에 의무를 따르지 않을 동기가 적습니다.
- 용어정리
- Prebuilt Block Template (PBT) : Early deadline에서의 커밋할 tx list
- 방법
- 블럭N의 프로포저는 PBT를 모든 CN들에게 broadcasting
- 블럭N+1의 프로포저는 앞에서 전파받은 PBT에 Auction + Lend 을 덧붙여서 블럭N+1을 마이닝
- 블럭N+1을 검증
- Invariant:
B[N+1] - PBT[N+1] = {auction tx, lend tx} or {}
- auction tx의 발견
- 블럭N+1의 프로포저의 서명확인
- 옥션tx의 옥셔니어 시그니쳐 필드가 옥셔니어의 서명인지확인
- lend tx의 발견
- 블럭N+1의 프로포저의 서명확인
- lend tx 뒤 따라오는 트랜잭션 2개(approve, swap)을 확인
- A, S가 PBT에 포함되어있는지 확인
- KIP-245에 따른 검증 (예: L,A,S의
to address가 whitelisted ERC20 인지 확인)
- 문제점
-
- 옥션 우회 공격
- S tx가 블럭N의 프로포저가 만든 tx이고, 블럭N+1 프로포저가 옥션tx를 삽입 하지않으면서 target tx hash에 곧이어 GA 번들링(LAS)을 붙여 넣을 경우 위의 로직에서는 유효하므로 프로포저가 간접적으로 옥션을 탈취할 수 있습니다.
- 단, N블록 프로포저와 N+1블록 프로포저와 이해관계가 있어야 하며 이해관계가 없다면 옥션 tx를 삽입하지 않을 동기가 없기때문에 이러한 attack path는 최소 2명의 악의적인 프로포저가 협심해야 합니다.
- 예제)
- PBT =
[target_tx, S]
- 기대 시나리오 =
[target_tx, auction, LAS]
- 공격 시나리오 =
[target_tx, LAS] (bid 소모없이 GA 번들링으로 backrun 실행)
- PBT 방식자체의 문제점과 해결방안
- 문제점1
- 매블럭마다 CN들에게 전파되는 PBT의 유효성 검증문제
- 해결방안1
- PBT의 서명값이 직전 블록 프로포저의 서명값인지 확인
- 문제점2
- 다음 블럭의 프로포저가 제안할 블럭의 tx list를 직전 블록의 프로포저가 미리 생성하는 흐름에 의하여 임의로 조작한 블럭을 넘길 수 있습니다. 임의로 조작된 블럭은 state를 위반하는 트랜잭션이거나, 트랜잭션을 포함하지않아 가스 수수료를 얻지 못하는 등의 공격을 할 수 있습니다.
- 해결방안 제안
- PBT 방식에서는 블록 프로포저는 현재 블록 뿐만 아니라 다음 블록의 템플릿까지 만들어야하는 추가 의무를 수행하여야 합니다. 따라서 블록보상을 현재 블록과 다음 블록을 강결합하여 블록 보상 메커니즘을 다음과 같이 수정이 필요합니다.
- 블럭간 강결합 보상
- 현재 블록의 보상을 5:5의 비율로 직전 프로포저와 현재 프로포저에게 분배 합니다.
2. Auction In Non-consensus
목표: Validator의 악의적인 행동 탐지
- Validator는 모든 거래에 대해 충분한 경매시간이 보장될 수 있도록 조기 마감 기한 (early deadline)을 준수해야 한다.
- Validator는 프로토콜 규칙에 따라 경매를 처리해야 한다.
기본 개념
Auctioneer는 이미 각 validator들로부터 pending transactions들을 수신하고 있으므로, validator가 조기 마감 기한을 준수하는지 확인하기 위해 추가적인 메시지인 MSM (Mining Start Message) 를 활용할 수 있다.
- MSM: 각 검증인은 채굴이 시작되자마자, 블록 내 모든 거래의 정렬된 해시 목록과 해당 블록 번호를 경매 진행자에게 전송한다. 즉, MSM 메시지는 다음과 같은 구조를 가진다:
{hashes, miningBlockNum}
즉, 옥셔니어는 websocket을 통해 각 validator들로부터 다음과 같은 메세지를 받으며, 이를 로컬 타임과 함께 기록한다.
- Pending transactions: 기존
eth_subscribe[“newPendingTransactions”]과 유사하지만, full transaction을 전송.
- MSM: Validator가 블록 마이닝을 시작하자마자 전송.
여기서 중요한 점은, 옥셔니어는 MSM에 기록되어있는 hashes의 존재를 이미 pending transactions을 통해 전달받았을 것이라는 점입니다. 따라서 예상되는 메세지 수신 타이밍은 다음과 같습니다.
tx -> Val1: Receives transactions and add it to pending pool.
Val1 -> auctioneer: Sends newly added pending transaction.
...
Val1 -> auctioneer: Sends MSM
예를들어, Val#1은 다음과 같이 옥셔니어에게 메세지를 전송하고 있습니다.
Val1 -> Auctioneer: [... {hashZ, N-1}], [A, B, C, D {hash{A, B, C}, N}], [E, F, G, {hash{D, E, F}, N+1}], [H, I, {hash{H, I}, N+2}], ...
위 예시에서, 옥셔니어는 Val#1이 proposer가 됐을 때 블록의 컨텐츠를 예상할 수 있습니다. 만약 Val#1이 블록 N+1의 proposer라면, 블록 N+1은 {D, E, F}를 담고 있어야 하며, 마지막 트랜잭션은 F 라는 것을 알 수 있습니다.
또한 이미 위에서 이야기했듯, 옥셔니어는 MSM을 받기전 이미 pending transactions을 통해 각 tx 메세지를 로컬 타임과 함께 기록해 두었고, 이를 이용하여 proposer가 사용한 early deadline을 계산할 수 있습니다.
// In auctioneer's local time
Tx D: 00:40
Tx E: 00:63
Tx F: 00:85
<- Early deadline
Tx G: 00:93
MSM : 01:05 {D, E, F}
위의 예시에서, 우리는 proposer가 F, G 사이에서 early deadline을 끊었다는 것을 알 수 있고, 이는 최소 01:05 - 00:93 = 00:12의 early deadline을 보장했다는 뜻입니다. 이는 모두 이상적인 네트워크 환경에서의 예시이며, 실제로는 여러 변수가 존재하기 때문에 우리는 계산된 early deadline이 기대치를 벗어나는 경우가 1. 매우 의심가는 상황이거나 2. 특정 validator에게 자주 발생했을 때를 기준으로 proposer의 malicious함을 사후 평가할 수 있습니다. 이 기준은 생태계 참여자들과의 토의를 통해 결정될 수 있습니다.
다음으로 트랜잭션 삽입 관점에서, 블록은 옥셔니어가 모르는 트랜잭션을 포함할 수도 있습니다. 이는 크게 두 가지 케이스가 존재합니다:
- 수신받지 못한 tx가 last tx 이전에 들어온 경우:
D, *G*, E, F
- 만약
G가 번들링으로 인한 tx거나, 정상적인 전파과정을 거쳤다면, 문제가 없습니다.
- 만약
G가 proposer가 삽입한 임의의 tx라면, 이는 옥션과 별도의 문제입니다.
- 수신받지 못한 tx가 last tx 이후에 들어온 경우:
D, E, F, *G*
- 만약
G가 번들링으로 인한 tx라면, 문제가 없습니다.
- 만약
G가 proposer가 삽입한 임의의 tx라면 해당 proposer는 룰을 지키지 않았다고 확신할 수 있습니다.
다음으로 번들 처리관점에서, 옥셔니어는 옥션 결과를 최대한 많은 CN에게 전달하며, CN도 내부적으로 broadcasting을 진행합니다. 즉, 옥셔니어가 정상적으로 옥션 결과를 발송했다면 validator는 이를 블록에 포함시켜야 합니다.
- 만약 옥션 결과가 static validation을 통과하지 못했다면: Offchain으로 검증할 수 있습니다.
- 만약 프로포저가 옥션 결과를 받지 못했다고 주장한다면: 다른 CN들은 옥션 결과를 정상적으로 수신했고, 다른 모든 CN들로부터 전파도 받지 못했을 확률은 매우 낮으므로 반복적일 경우 malicious하다고 추정할 수 있습니다.
위의 방법론을 사용해서, 우리는 CN client의 변화를 최소하하면서도 validator의 malicious한 행동을 발견할 수 있습니다.
이를 사용하여, 우리는 malicious한 validator를 발견/처벌할 수 있습니다. 이전에 온체인 거버넌스에 지속적으로 참여하지않은 validator들을 network에서 제거했듯이, permissionless 전까지도 이를 발견하여 적절한 조치를 취할 수 있을 것이라 기대합니다.
Note: node에서 tx.time을 찍는 시점을 pending list에 추가하는 시점으로 수정해야 합니다.
수신 삽입 마이닝
Tx1: ------------|------------|-----------------|------
수신 삽입
Tx2: --------------|----|-----------------------|------
^ Early-deadline
즉, 수신을 기준으로하는 early deadline은 통과하지만, 실질적으로 "삽입"이 되어서 auctioneer에게 전달한 이후로부터는 충분한 early deadline이 보장되지 않음.