The main inspiration for this post is that I was capable of finding an easy way to bring down the hosted sophia compiler service… The compiler recovered after some time and was scaled up but unfortunately it is still easy to bring down this service.
The main problem with our current ecosystem is that although our core nodes are fully decentralized and trustless, AEPP’s rely on a centralized compiler service in order to interact with sophia contracts. This has several implications for users of Aeternity, Superhero, Hyperchains:
- AEPP users either need to trust the provided compiler http service or they need to host their own compiler in order to maintain privacy. Hosting a compiler on windows/android/ios won’t be an easy task
- Usually AEPPS don’t allow you to change the compiler URL. This essentially means that even if you have your own compiler then you still need to trust a operator.
- If you host your own compiler my attack vector still applies and it is easy to bring it down your compiler service…
- It’s impossible to host an AEPP as a static site while maintaining trustlessness…
- Wallets are incapable of decoding contract calldata in order to introspect interactions with contracts
- There is no way to verify whether the compiler is lying to us without actually encoding call data on the client side
- The compiler can track users, modify calldata easilly etc…
This thread proposes a new nice approach to finally fix those issues once and for all. Our saving grace is that both Aesophia and Aebytecode do not require sophisticated OTP features so they are feasible for transpilation to other languages. Previously we have anticipated that https://github.com/lumen/lumen will reach a state where aesophia and aebytecode can be compiled to WASM, but it will take Lumen still a lot of time to reach this state.
Creating an alternative “competing” implementation of aebytecode/aesophia isn’t the way to go as those implementations would need to be kept in sync…
- We port the existing core parts(aeserialization, aebytecode, aesophia) of the codebase to PureScript
- We transpile the core parts to both JS and Erlang (and C if you want more performance)
- We deprecate the old Erlang only implementation and the Purescript one becomes the main source of truth
In order to show that the approach is feasible it would be nice to port at least aeserialization and aeb_fate_encoding.erl from aebytecode to Purescript, which then can be used immediately by the SDK, Superhero project etc…
I would like to see as many people as possible voicing their opinion on this topic: @yani.chain @contributor
If the ansalt agrees this proposal might become part of either the Hyperchains or Superhero project.