Using git's workflow as an analogy for [delta] 's
@deltadotnetwork
>>>
>>>
>>> git commit -m "delta workflow"
>>>
>>>
Let’s assume there’s a project whose master branch [account state] lives in a monorepo [single state].
A developer [server as domain operator] writes code [operator orders and executes user transactions], resulting in code changes [state diffs]. Alternatively, some devs like to work in groups [decentralized network as a domain operator] and come up with code changes after they have reached consensus.
Subsequently, they create a branch and push these code changes to it [submit SDL; SDL is included in the state as a result].
Once they are ready [have produced a proof for the submitted SDL], they open a PR [submit SDL proof]. The code reviewers [validators] review the changes [verify the submitted proof].
If approved, the code changes receive the required number of approvals per branch protection rules [at least quorum-many validators attest to the proof’s validity]. As a result, the code changes are merged into the codebase [diffs included in the SDL are applied to the account state].
Moreover, let’s assume that, for this repo, merge conflicts must be prevented [double-spending risk must be eliminated]. Thus, each file [vaults registered under the same domain] can only be modified by a single dev [can only spend through their associated domain].
This is [delta].