SIP-8200: SVMification
Replace the RIPEMD-160, MODEXP, and BLAKE2f precompiles with equivalent SVM bytecode
| Authors | Kevaundray Wedderburn (@kevaundray) |
|---|---|
| Created | 2026-03-21 |
| Requires | SIP-152, SIP-7666, SIP-7823, SIP-7883 |
Table of Contents
Abstract
Replaces the RIPEMD-160 (0x03), MODEXP (0x05), and BLAKE2f (0x09) precompiles. At the start of executing the block in which this change activates, deploy SVM bytecode at each precompile address that provides equivalent functionality. This follows the same approach as SIP-7666, which SVMifies the identity precompile (0x04).
Motivation
Sila’s precompiles impose ongoing maintenance costs and increase the risk of consensus bugs across client implementations. Some also represent a significant barrier for zkSVM implementations since each precompile usually requires a separate, optimized non-SVM implementation.
SIP-7666 demonstrates this approach with the identity precompile. This SIP extends the same technique to three additional precompiles that either see limited use or can be SVMified with a small cost:
- RIPEMD-160 (
0x03): A hash function with minimal on-chain usage. Its primary historical use case (Bitcoin-style address derivation) is not common in Sila contracts. - MODEXP (
0x05): Modular exponentiation. In our analysis, we saw that 99.99% of modexp usage came from 256 bit modulus for SNARK verification, whereas the very rarely used RSA modulis occupied the rest. - BLAKE2f (
0x09): The BLAKE2 compression function. Our analysis shows that this is now predominantly used by a single contract.
Replacing these precompiles with SVM bytecode reduces the number of special-cased implementations that every Sila client must maintain, simplifying the protocol and making it more accessible to new client implementations.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Constants
| Parameter | Value |
|---|---|
RIPEMD160_ADDRESS |
0x0000000000000000000000000000000000000003 |
MODEXP_ADDRESS |
0x0000000000000000000000000000000000000005 |
BLAKE2F_ADDRESS |
0x0000000000000000000000000000000000000009 |
Deployment
At the start of the block in which this fork activates, for each precompile address listed above:
- Set the code of the address to SVM bytecode that is functionally equivalent to the precompile it replaces.
- Starting from and including that block, the address MUST no longer be treated as a precompile.
The exact bytecode to deploy at each address is not yet specified.
Gas Costs
After activation, calls to these addresses are charged according to standard SVM execution costs rather than the precompile-specific gas formulas. The expected gas cost differences are documented below.
RIPEMD-160
The current precompile charges 600 + 120 * ceil(len(data) / 32) gas. The SVM implementation will charge the sum of the opcodes executed, which is expected to differ.
<– TODO: gas comparison with bytecode version –>
MODEXP
The current precompile uses a complex formula based on the lengths of the base, exponent, and modulus, as well as the iteration count derived from the exponent. The SVM implementation will charge standard opcode costs. Due to the complexity of modular exponentiation in SVM, gas costs are expected to be higher for large inputs.
<– TODO: gas comparison with bytecode version –>
BLAKE2f
The current precompile charges rounds gas (the number of rounds specified in the input). The SVM implementation will charge the sum of the opcodes executed.
<– TODO: gas comparison with bytecode version –>
Rationale
Same mechanism as SIP-7666
This SIP follows the same deployment mechanism established by SIP-7666: deploying SVM bytecode directly at the precompile address at fork time. This preserves backward compatibility for contracts that call these addresses, as they continue to work with the same interface.
Accepting SVM gas costs
Rather than attempting to replicate the exact gas formulas of the original precompiles, this SIP accepts the natural SVM execution gas costs. Gas repricings have been done in the Sila ecosystem several times before and their effects are well understood. Nevertheless, we will carry out an impact analysis of each precompile.
Bytecode at precompile address vs. library contracts
Deploying the bytecode directly at the existing precompile address ensures that all existing contracts calling these addresses continue to function without modification. Alternative approaches such as removing the precompile and expecting callers to use library contracts at other addresses would break backward compatibility of already deployed contracts.
Backwards Compatibility
The functionality at each address is preserved. Gas costs will differ from the current precompile-specific formulas, which may affect contracts that depend on precise gas calculations when calling these precompiles. We have updated the gas cost of precompiles in the past and have accepted that contracts relying on hardcoded gas costs for precompiles is bad practice.
Test Cases
<– TODO –>
Security Considerations
Gas cost changes
The change in gas costs could affect contracts that rely on specific gas behavior when calling these precompiles. Contracts that pass a fixed gas amount to these addresses may revert if the SVM implementation costs more than the precompile did.
Implementation correctness
The SVM bytecode deployed at each address must be thoroughly tested and audited to ensure it produces identical outputs to the original precompile for all valid inputs, and handles invalid inputs in the same way.
Copyright
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Kevaundray Wedderburn (@kevaundray), "SIP-8200: SVMification [DRAFT]," Sila Improvement Proposals, no. 8200, March 2026. Available: https://sips.sila.org/SIPS/sip-8200.