Skip to content

[FR] Add host method(s) to allow calls to occur between FAT-0 contracts on the same chain #54

@drkatz

Description

@drkatz

Is your feature request related to a problem? Please describe.
No, this issue requests adding new functionality not based on an existing issue or bug.

Describe the solution you'd like
Add method(s) to the existing host interface supplied to FAT-0 WASM contracts to allow them to call other contracts established on other Factoid Addresses on the same FAT-0 chain.

Currently contracts are isolated, and can only access functions that are internally available in their own WASM module code. This change will allow a contract's WASM code to call externally available ABI exported functions in other contracts, and by extension, access their state. This will enable smart contracts to be built upon each other in a composable way and allow them to interact in more complex ways than is currently allowed.

Examples where this functionality is required:

  • Check a condition is satisfied in an existing contract
  • Check the balance of a "virtual" FAT token (A token implemented in WASM code on top of an existing FAT token)
  • Interact with or get data from a bridge contract that maintains and validates the state of another blockchain (Ethereum bridge for example)

The following will be required:

  • Create a host interface function to execute a cross contract call, for example consider the function signature call(<Contract Factoid Address>, <Function Name>, <Function Arguments[]>) executable by a WASM contract
  • Create a host interface function to allow a contract to check whether a Factoid address is an established contract. This allows contracts to control and regulate behavior when called by another contract

Standards Affected:

  • FAT-105 Host Interface Standard: Specifies what host methods are available to a contract. Part of larger smart contract pull request as part of Factom Protocol grant
  • FAT-0 Will also need to be modified to be explicit about how cross contract calls are handled and validated when it comes to maintaining token state.

Affected files within FAT Daemon (Not exhaustive):
internal/runtime:

  • context.go - Manages the execution context for calling contracts, used by imports.go to return the proper values and when calling host methods
  • imports.go - Lays out internal workings of host functions, function to call function in another contract and function to check if the current call is originated from a contract will need to be added. Call to execute function in another contract will need to reference runtime.go and create new instances to execute chained calls
  • runtime.syms - Add function signatures added to imports.go

Describe alternatives you've considered
Use Ethereum 😢

Additional context
The addition of this feature will be carefully considered and spec'd out before implementation, as it represents a myriad of potential vulnerabilities that we've seen in systems such as Ethereum that enable similar functionality. This issue description is only meant as a rough outline and will be amended over time.

Before this functionality is implemented a Gas system will need to be devised to regulate the expense of executing:

  • Intentionally or unintentionally malicious expensive contract calls
  • Naturally expensive legitimate contract calls
  • Circular or recursive contract calls

FAT is intended to allow segregation of computation via Factom Chains. This addition adheres to this philosophy as the token state remains constrained to a single token chain. This allows the --whitelist and --blacklist command line flags to remain part of FAT daemon functionality and allows users to only need to download, validate, and calculate the state for contracts that they are interested in.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions