Finalizing BITE Protocol Phase 1: Transaction Format Proposal

dApp Developers
1

Hey folks,

As we finalize BITE Protocol Phase 1, we need to agree on the final format for the Phase 1 BITE transaction.

After discussions with Oleg, here is the proposed format:

  1. We replace the original transaction to address with BITE_MAGIC_NUMBER, a special purpose Ethereum addess selected once and forever.
    → Our current BITE_MAGIC_NUMBER will be extended with 4 random bytes to form a full 20-byte address.

  2. As a result, we no longer need to include BITE_MAGIC_NUMBER in the data field.

  3. We adopt RLP encoding for the plaintext payload, for the following reasons:
    a) RLP is widely adopted in the Ethereum ecosystem, which lowers the learning curve.
    b) It is inherently extensible, allowing us to add new fields in the future.
    c) Many security-audited libraries exist for RLP encoding across various programming languages.

  4. We allow users to obfuscate the plaintext by appending a random vector of arbitrary bytes to the plaintext before encryption
    → Since users pay 8 gas per byte for CALLDATA anyway, they can choose how much obfuscation to apply.
    → Libraries can offer sensible defaults (e.g., appending 10% extra obfuscation bytes).

Final Data Format

transaction_to_address = BITE_MAGIC_NUMBER
transaction_bite_data_field = rlp_encode(bite_payload)

Where bite_payload is:

bite_payload = {
uint64_t epoch,
uint64_t threshold_encrypt(aes_gcm_key),
uint8_t[] aes_gcm_encrypt(rlp_encode(bite_data))
}

Where bite_data is:

bite_data = {
uint160_t original_to_address,
uint8_t[] original_data,
uint8_t[] threshold_encryption_random, // Random value used to validate threshold encryption
uint8_t[]  obfuscation_bytes_of_random_length // Random length byte array for obfuscation
}

Comments are welcome!

2

hey Stan! thanks for the great discussion we had before. one question that I forgot to mention is should we explicitly deny users an opportunity deploy smart contracts using BITE protocol or should we create another flag for it in an encrypted data we submit? the reason I am asking is to field stays empty for the creation transactions and these transactions require more gas to be completed. so sending a creation transaction using BITE protocol may lead to the scenario where a transaction is found valid although user doesn’t have enough funds to execute it.

1 Like
3

Good point !

May be we should not support contract creation in the first version. There are little use cases for it.

One additional reason not to allow BITE for contract creation is we might use AI in the future to prevent malicious contracts to be deployed by SKALE. AI will require source code and bytes of the smartcontract to be public for analysis.

1 Like
4

Hey @kladkogex

It’s unclear how your proposed solution may impact compatibility with common tools and standards like Metamask. Can you please confirm when you say that the BITE_MAGIC_NUMBER would go in the original to address, do you mean that it would look like this:

let tx = {
   to: BITE_MAGIC_NUMBER + 4_RANDOM_BYTES,
   data: rlpEncodedBiteData
}

where as currently it works as such:

let tx = {
   to: 0xnormalEVMAddress,
   data: `0x${BITE_MAGIC_NUMBER}${ENCRYPTED_TX_DATA}`
}

I do think a big positive here could be that it adds increased privacy to the transaction. The removal of the to field directly would make it even harder for search/MEV bots to determine what might be occurring as well I would think?

Thanks!

@olehnikolaiev – my opinion is that smart contracts should be deployable as encrypted txs if possible at some point. I think it could open some interesting usecases around single-use contracts, smart accounts, and even tokens. Areas I think this could potentially be really interesting:

Improved Smart Contract Upgrades

Currently, when upgrading smart contracts it’s generally fairly simple to follow an upgrade for major protocols. This could potentially give public DAOs/protocols the ability to upgrade with maybe a little less risk

Improved Fair Launches

With many tokens utilizing OpenZeppelin and other standard libraries for launch; the ability to launch with an encrypted transaction would in theory allow them to deploy without having people know about it right away, making things more fair.

Overall – this is actually probably more relevant for factories than direct deployments. I think as long as deployments can be done via factory contracts for launchpads, AMM LP Pairs, etc which would be more of just a normal transaction then it should be acceptable to most developers.

5

Hey Sawyer — yep, we’re keeping the tx.to field. All encrypted BITE transactions will have BITE_MAGIC as too.

It should keep tool compatibility smooth, but we’ll test it!

1 Like