4.0.0

What's Changed

4.0.0 release introduces several sweeping changes to the Wallet Core, primarily centering on the shift from C++ to Rust for improved performance, security, and maintenance:

1. Elliptic Curves in Rust: We've successfully migrated most of the currently supported elliptic curves to Rust. Implementation details are as follows:
   • secp256k1 - using RustCrypto: k256
   • ed25519, ed25519-blake2b, ed25519-cardano-extended - using curve25519-dalek
   • nistp256p1 - using RustCrypto/p256
2. Wallet Core Redesign: Exploiting Rust's robust type system, the Wallet Core design has been massively enhanced to promote easier implementation of features and long-term code maintainability.
3. Ethereum Transition: We've shifted the main Ethereum functionality from C++ to Rust. The implementation encompasses Ethereum's basic operations, RLP and ABI interfaces, as well as EIP712 message signing. As it stands now, the Ethereum transition is fully executed.
4. Bitcoin Transition: Progress is underway to move Bitcoin functionality from C++ to Rust. So far, this involves Bitcoin's basic operations and interface redesign. Pending tasks include:
   • Establishing a bridge between the legacy and new Bitcoin protobuf interfaces for seamless transition.
   • Shifting all tests to Rust.
   • Implementing other Bitcoin-related functionality in Rust.

Progress

• #3107
• #3146
• #3163
• #3169
• #3322
• #3350
• #3382
• #3440
• #3458

Breaking changes

• VeChain and Theta no longer support JSON signing. Initially, the chains inherited Ethereum::Entry, but Entry::signJSON was not overridden with the chain specific implementation.
• UserOperation signed transaction (JSON representation) now has the sender: Address field normalized with EIP55 checksum.
• Removed Ethereum::RLP::decode functionality as it's not used in C++.
• Ethereum and all EVM-compatible chains no longer support TWTransactionCompilerBuildInput.

Deprecated

• TWEthereumAbiFunction and all methods.
• TWEthereumAbiEncode. Consider using TWEthereumAbiEncodeFunction through Protobuf interface instead.
• TWEthereumAbiDecodeOutput. Consider using TWEthereumAbiDecodeParams through Protobuf interface instead.
• TWEthereumAbiDecodeCall. Consider using TWEthereumAbiDecodeContractCall through Protobuf interface instead.
• TWEthereumAbiValueDecodeValue, TWEthereumAbiValueDecodeArray and all TWEthereumAbiValueDecode*. Consider using TWEthereumAbiDecodeValue through Protobuf interface instead.