Because of this, it is well suited to for the job of writing the specification for the protocol where abstraction, precision and succinctness matter.
Having higher level of abstractions gets Superfluid protocol closer to being able to formal definitions in category theory e.g.
Developers using Haskell tend to be more comfortable in refining concepts and constant refactoring, sometimes pedantically. But production code usually can't afford these due to harder to refactor than using Haskell.
Why Simulation Environment?
An integrated experience for fast prototyping of new concepts.
Easy to share and demonstrate the foundational tech.
Why Test System?
Re-use the simulation environment but for controlled tests.
As the basis for implementation validations.
Requirements
The validator should be able to run in at least two different modes
Web App Mode | A Simulation Environment with REPL
A web app that servers the simulation sessions in the backend, while frontend reads the state of the simulation and renders them.
The state of the simulation mainly cosists of:
Global state: tokens, token statistics, etc.
Account state: real-time balances of accounts in testing, active agreements of the account.
Renderings of these states should include charts, timeline (with the ability to travel back-and-forth in time), etc.
User inputs should support simple DSL with a REPL like interface.
!NB! We are still sourcing the development partner for this
Why this is being developed?
Superfluid specification is being built up as a set of concepts defined in the superfluid-protocol-spec-core haskell module.
Why Specification?
Why Haskell?
Why Simulation Environment?
Why Test System?
Requirements
The validator should be able to run in at least two different modes
Web App Mode | A Simulation Environment with REPL
Tester Mode