` mapping. Since the names of public entrypoints will likely not be mangled - the rust mangling scheme is not stable yet and we need to interop with C and one day move programs too - could we use symbol names? If we can use symbol names then essentially we don’t have to do anything special in the runtime, we already have a symbol table so we can just lookup.
---
### Author:  [@toly](https://forum.solana.com/u/toly)
#### Post date: [May 25, 2023, 8:54pm UTC](https://forum.solana.com/t/srfc-00015-interfaces/267/7 "2023-05-25T20:54:07Z")
So with Runtime V2 something like this should work
```auto
///token.rs
///Token Transfer interface
struct Token {
authority: Pubkey,
balance: u64
};
trait Token {
fn transfer(from: &mut Token, to: &mut Token, amount: u64) -> Result<()>
}
```
then the implementation can look like this
```auto
///mytoken.rs
///my token implementation, counts the number of balance transfers
struct MyToken {
token: Token,
counter: u64,
}
impl Token {
fn transfer(from: &mut Token, to: &mut Token, amount: u64) {
let from: &mut Account = to_account(from);
let from: &mut MyToken = from_account(from);
from.counter += 1;
from.token.transfer(to, amount);
}
}
```
---
### Author:  [@ripatel-jump](https://forum.solana.com/u/ripatel-jump)
#### Post date: [May 26, 2023, 12:01am UTC](https://forum.solana.com/t/srfc-00015-interfaces/267/8 "2023-05-26T00:01:59Z")
@toly would PRv2 support dynamically dispatching this trait? This looks very interesting. How would we address (lack of) ABI stability in rustc v1.x.x?
---
### Author:  [@toly](https://forum.solana.com/u/toly)
#### Post date: [May 26, 2023, 12:39am UTC](https://forum.solana.com/t/srfc-00015-interfaces/267/9 "2023-05-26T00:39:37Z")
It should be equivalent to a global extern function in C.
Do you mean dispatching from the transaction message processor or between programs? I think the tricky part will be figuring out which token implementation gets called when more then one is present.
I think we will need to be able call the extern functions from the program object.
---
### Author:  [@splintr](https://forum.solana.com/u/splintr)
#### Post date: [May 26, 2023, 12:54am UTC](https://forum.solana.com/t/srfc-00015-interfaces/267/10 "2023-05-26T00:54:20Z")
I’d like to suggest that interface GUID’s should be the first 128 bits of a hash of the specification detailing what accounts/data the interface expects. This convention should prevent contention/confusion over specific ID’s (ie low # ID’s).
Additionally, I’d like to note that there is a need for data interfaces. For example, for any ownable object, it should be possible to determine the owning address. In different implementations that owner may be stored at different offsets into an account. It would be a huge burden on indexers/applications to require that these offsets be found manually. Additionally, a single program may have multiple different account types, so these offsets might be different within a single program.
I propose a solution in two parts: Account discriminators and an offsets section within the ELF. The idea would be that, within the binary, each different discriminator would be followed by a list of interface-offset pairs, designating the location within each account that the interface’s data can be found.
Note: If I remember correctly, some current implementations vary account type via account size. These implementations will need to be manually grandfathered in by indexers. In fact, since these implementations already exist and are indexed, it would require minimal work. However, all future programs would need to adhere to the discriminator system.
---
### Author:  [@cavemanloverboy](https://forum.solana.com/u/cavemanloverboy)
#### Post date: [June 9, 2023, 4:11am UTC](https://forum.solana.com/t/srfc-00015-interfaces/267/11 "2023-06-09T04:11:10Z")
if I understand correctly, it seems to me like this goes against last year’s trend of composability (since everyone has their own impl of a primitive), will contribute to chain bloat, and opens up a can of worms re: vulnerability.
1. Why are these issues not a concern?
2. How big is the byte code for each interface implementation (e.g., for these simple transfers)?
3. Are there any guarantees about state transitions that can be provided beyond Rust/Move aliasing rules? For example, instead of a `&mut self`, can we mark only part of state as mutable for a given implementation? Also, as another example, can we provide default implementations for particular methods that cannot be overwritten.
To illustrate this last point, consider another take on your last example:
```rust
struct Token {
authority: Pubkey,
balance: u64
};
trait Token {
fn transfer_hook(from: &mut Token, to: &mut Token, amount: u64) -> Result<()>
#[immutable]
fn transfer(from: &mut Token, to: &mut Token, amount: u64) -> Result<()> {
let to_account: &mut MyToken = to_account(to);
let from_account: &mut MyToken = from_account(from);
from_account.token.transfer(to_account, amount);
transfer_hook(from, to, amount)
}
}
```
and
```rust
struct MyToken {
token: Token,
counter: u64,
}
impl Token for MyToken {
fn transfer_hook(from: &mut Token, to: &mut Token, amount: u64) {
let from: &mut MyToken = from_account(from)
from.counter += 1;
}
}
```
which provides the same functionality while providing a base implementation that need only be audited once.