WEP 13: dApp invocation by transaction id

Abstract

This proposal is about an ability to make dApp invocations by transaction id (txId) of latest account script of dApp.

For this purpose, the following improvements are needed:

  • Add the ability to call dApp by a txId (in addition to Address|Alias).
  • Resolve dApp account by this txId.
  • Check that a currently active script of the account was set by this txId.
  • Return an error if the current script of the account was set by different txId.
  • Do regular Invoke Script Transaction stuff.

Motivation and purposes

Currently, dApp users must trust dApp developers if dApp`s account script allows changes.

The new functionality guarantees dApp users that they call the exact account script as was audited. And if a script changes users will get an error and can audit code and update their invocation procedures.

Example:

Before WEP 13:
  • user calls dApp as address + function + payment
  • dApp script changes
  • invocations still work
  • user code was not ready for new changes
  • user loses tokens
After WEP 13:
  • user calls dApp as txId + function + payment
  • dApp script changes
  • invocations fail
  • user can audit and adopt
  • user saves tokens and earn more
3 Likes

Instead of txId it could also be hash of a script.

How do you find an dApp address by this hash of a script? Invoke address + function + payment + hash?

The main idea is to use the existing arguments, not a new one.

Means that will be possible to continue to run an older version of a dapp?

Of course not, the proposal is going to trigger an error if a script logic changes.

For now you need to track changes manually.

Imagine dApp-to-dApp is activated and you call inside your dApp some other dApp swap() function but its new version just eats all your payments and returns nothing.

Without this proposal there is no mechanism to ensure that this does not happen.

1 Like