You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use excellent Parity libraries to send ETH transactions and make use of our contracts. However Parity doesn't support MIPS and they seemingly doesn't have plans to do so. We put a lot of effort into trying to get it right but getting deeper into the rabbit hole gave us more and more crates that won't support MIPS and big endian byte order. Our needs aren't that big - while Parity is really big set of libraries that probably implements whole ETH node we use it only to sign transactions, and to compile contracts parameters into data. Given the problems and our use case clarity was born.
Solution
We plan to swap all types that we use that are made by Parity to replace them with similar types provided by Clarity. Whenever a missing piece of functionality in Clarity is found it should be reported on Clarity repo, and a workaround has to be found if a nontrivial amount of work is required to cover it.
Plan
Remove dependency on ethereum_types
Replace ethereum_types::Address into clarity::Address
Replace ethereum_types::U256 into clarity::BigEndianInt
Remove dependency on ethkey
Replace ethkey::* types that could be simplified with a clarity::Transaction and clarity::PrivateKey - especially in crypto.rs
Cover missing functionality in crypto.rs especially verify and and hash_bytes methods with functionality provided by Clarity
Remove dependency on ethabi
Replace contract generation with precomputed values (or computed ourselves) (See ABI support clarity#21 for a proposal for adding support for ABI compilation in clarity)
eth_client.rs - Replace Transaction type to use Transaction from clarity.
In clarity a SignedTransaction replacement is a Transaction - it just differs if it has a signature or not.
Risks
We rely on U256 from ethereum-types and it should be noted that clarity uses a BigInt from num_bigint crate. There is some effort involved on althea_rs side.
Problem
We use excellent Parity libraries to send ETH transactions and make use of our contracts. However Parity doesn't support MIPS and they seemingly doesn't have plans to do so. We put a lot of effort into trying to get it right but getting deeper into the rabbit hole gave us more and more crates that won't support MIPS and big endian byte order. Our needs aren't that big - while Parity is really big set of libraries that probably implements whole ETH node we use it only to sign transactions, and to compile contracts parameters into
data
. Given the problems and our use case clarity was born.Solution
We plan to swap all types that we use that are made by Parity to replace them with similar types provided by Clarity. Whenever a missing piece of functionality in Clarity is found it should be reported on Clarity repo, and a workaround has to be found if a nontrivial amount of work is required to cover it.
Plan
ethereum_types
ethereum_types::Address
intoclarity::Address
ethereum_types::U256
intoclarity::BigEndianInt
ethkey
ethkey::*
types that could be simplified with aclarity::Transaction
andclarity::PrivateKey
- especially incrypto.rs
crypto.rs
especiallyverify
and andhash_bytes
methods with functionality provided by Clarityethabi
eth_client.rs
- ReplaceTransaction
type to useTransaction
from clarity.SignedTransaction
replacement is aTransaction
- it just differs if it has asignature
or not.Risks
num_bigint
crate. There is some effort involved onalthea_rs
side.The text was updated successfully, but these errors were encountered: