[Feature]: Add Function That Creates Account from a String Seed

[0xNeshi]

What is the feature you would like to see?

Account

It would be ergonomic to allow devs to pass an arbitrary string (or even number) as a "seed" from which a private key for Account can be derived, generating its Address.
This would be similar to existing conventions in Solidity Foundry & Starknet Foundry.

As Account creation from &str should be infallible, it should be perfectly appropriate to just implement impl From<&str> for Account.

Additionally, we might want to enable const Account instances. For this, we'll need a dedicated const fn.
Example implementation:

    // we could even make this generic if you have any suggestions, though difficult to do with `const`.
    #[must_use]
    pub const fn new(seed: &str) -> Self {
        let hash = Keccak256::new().update(priv_key.as_bytes()).finalize();
        Self { address: Self::bytes_to_address(&hash) }
    }

    const fn bytes_to_address(bytes: &[u8]) -> Address {
        let mut addr_bytes = [0u8; 20];
        let mut i = 0;
        while i < 20 {
            addr_bytes[i] = bytes[i];
            i += 1;
        }
        Address::new(addr_bytes)
    }

Later in tests, it would be possible to do the following:

#[cfg(test)]
mod tests {
    const CHARLIE: Account = Account::new("charlie");

    #[motsu::test]
    fn some_test() {
        // before
        let alice = Account::new_at(address!(
            "A11CEacF9aa32246d767FCCD72e02d6bCbcC375d"
        ));
        let bob = Account::new_at(address!(
            "B0B0cB49ec2e96DF5F5fFB081acaE66A2cBBc2e2"
        ));
        // after
        let alice = Account::from("alice");
        let bob: Account = "bob".into();
        // ...
    }

We also make it clear that we prefer devs manually set addresses in order to avoid potential collisions (although the chances are fairly low).

This also ties naturally into how real EOAs are instantiated (with private keys), implying that priv_key should be unique, and if there are collisions, it's the dev's fault.

If devs still prefer to get random address, they can use ::random().

This strikes a perfect balance between safety and devX.

Original message: #14 (comment)

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines