Nest: Pando Q3 Update

This second milestone was quite busy.

ETH Berlin

We had the chance to introduce Pando in various meetups during ETHBerlin. The feedback was awesome. But more on that soon.

Development

Regarding the dev side we re-organized our roadmap: we focused on re-architecturing the Pando's core smart contracts and postponed the CLI optimization to milestone 3 - the good news being: this optimization is on its way as the Pando CLI can now stage the whole react monorepo in a matter of seconds :)

It took us a lot of time to figure out what was the best architecture for the Pando app in order to

enable everyone to build their own governance kit on top of Pando
enforce a generic Pando-specific workflow
offer an easy way to integrate the upcoming Pando front-end in the Aragon client

After six or seven refactorings we finally came up with an architecture we were satisfied with :)

Pando's architecture

Pando, as an aragonOS application, comes with three smart contracts: a PandoGenesis contract, a PandoLineage contract and a PandoAPI contract. All of these contract rely on a shared Pando library defining Pando's data structures and helpers to handle these datastructures.

Pando.sol library

This library defines shared data structures and a couple of helpers to handle them. The main data structures are the following.

Individuation

Individuations are Pando's equivalent of git's commits. However, individuations are not commits. Why? Because commits reflect both the local state and the shared / public state a of repository. When one commit reflects changes they made to a local repository they can easily synchronize it through the git push command. In Pando, every individuation needs to be approved by an underlying DAO. This means that any individuation can be rejected and that there is no immediate identity between the local state and the shared / public state of a repository.

Lineage

Lineages refers to the emission of non-transferrable token acknowledging one's belonging to the lineage tree of a repository. Lineage tokens can thus be granted to contributors for the individuation they submit, but also to dependencies, inspirations, etc.

PandoGenesis

The PandoGenesis contract handles the individuations - i.e. commits - of a repository. It keeps tracks of these individuations, maps them through their unique Individuation ID, and enforce fast-forward consistency.

PandoLineage

The PandoLineage contract handles the issuing of Native Lineage Tokens to acknowledge the belongings of contributors and dependencies to a repository's lineage tree.

PandoAPI

The PandoAPI contracts acts as an interface for all external interactions with the repository - and thus with the Genesis and Lineage contracts. Its purpose is to enforce the consistency of the Pando protocol state-machine.

Users do not directly individuate a repository. They create Requests For Individuation which must be sorted - accepted or reject - by the DAO.

Requests For Individuation can come bundled with Requests For Lineage. These Requests For Lineage can origin directly from the user to ask for a reward in return for their contribution, or be automatically filled by a package manager if the Request For Individuation introduces new Pando hosted / Pando addressable dependencies.

These Requests For Lineage must also be individually sorted - accepted or rejected - by the DAO. The difference is that accepted Requests For Lineages must also be valuated by the DAO: which amount of Native Lineage Token is going to be issued for this lineage's destination in case the related Request For Individuation is eventually merged.

The Pando protocol state machine makes sure the relationships between all of these requests are consistent: if a Request For Lineage is rejected by the DAO, its related Request For Individuation is automatically cancelled ; if a Request For Individuation is rejected by the DAO, its related Requests For Lineage are automatically cancelled ; a Request For Individuation can't be merged before all its Requests For Lineage are accepted; if a Request For Individuation is merged, its related Requests For Lineage are automatically issued; etc.

The PandoAPI contract makes no assumption about the governance model enforced by the DAO. Its goal is only to make sure that the core logic of the Pando protocol is enforced - and cannot be circumvented. It’s up to the community to write governance kits - mostly: enhanced voting apps - on top this API contract. Governance thus works as an additional layer on top of the PandoAPI.

Governance kits

Governance kits are voting apps built on top of the PandoAPI. These kits must implement the PandoKit abstract contract to comply with a minimum interface - and thus provide a minimum degree of interoperability between governance kits for the CLI. The second milestone release of Pando comes with two built-in governance kits.

DictatorKit

Enforce a maintainer-based governance à-la GitHub.

VotingKit

Enforce a Native Lineage Token-backed democratic governance to sort and valuate requests.

Benefits

This architecture makes the whole Pando contract ecosystem as clear as possible:

The PandoAPI contract can be upgraded - e.g. because of a security breach - without no intervention of governance kits developers. We just have to be careful not to break the API. This can be enforced by a semantic versioning system.
Whenever people want to upgrade / modify their governance kit, they are sure they won’t mess up the actual Pando contracts storage - and thus loose their history.
All governance kits need to go through the API to update the state of the repository. This way, we can make sure that, however badly coded they are, they can’t mess with the underlying PandoAPI, Genesis or Lineage state - otherwise the API contract will revert. This means: people can develop as messy governance kits as they want but they can’t mess up the actual repo thanks to the API checking everything is done right when it’s called.
All the governance logic / parameters are handled by the governance kits which means:
People can implement any governance scheme they want - QR, holographic consensus, etc. - without requiring us to think of all the hooks they could need in Pando to do so.
It makes it really easy to turn any repo into a human readable license through radspec as I had demoed on a dummy examples here: https://asciinema.org/a/yM56wVS4Je2bkbzU6Vq57brpP.
All the end-users interactions with a repository governance go through a governance kit contract - and via it, through a PandoAPI contract - which makes it really easy to build Aragon client compatible frontends for these governance kits with no need to circumvent the sandboxing restriction :)

Next steps

The next steps will be:

To update and optimize the CLI tool to reflect this architectural changes
Come with a front-end app for the dictator and voting kits - which should be pretty straight forward :)

By the way: we are looking for a frontend dev. The detailled announcement is here: https://github.com/ryhope/documentation/blob/master/jobs/frontend-dev.md. Feel free to share on your channels and networks!

See you soon folks!