Cardano Well-Architected Framework

[scarmuega]

Cloud-development platforms usually provide a "well-architected framework" that describes their view of how to approach the development of complex systems on top of their platforms.

Here are some examples:

• AWS: https://aws.amazon.com/architecture/well-architected
• Azure: https://learn.microsoft.com/en-us/azure/architecture/framework/

In essence, each framework provides a set of best-practices on how to approach different development disciplines, such as: security, reliability, performance-optimization, monitoring, tracing, etc.

Having a "Cardano Well-Architected Framework" in a similar fashion to the mentioned above would serve as useful guidelines for developer teams entering the ecosystem.

[Benjmhart]

100% in favor of something like this.

[scarmuega]

The following is a non-exhaustive list of topics to trigger a discussion regarding the content of what a Well-Architected framework for Cardano might include.

DISCLAIMER: I'm far from being an expert in most of the topics enumerated here. This list is my best-effort trying to extrapolate topics from similar frameworks (mainly cloud providers) to our context. Many topics are probably missing and present ones might require to be reframed.

Reliability

Principles

• Design for business requirements
• Design for failure
• Observability
• Automation
• Self-healing

Best Practices

• Permanent Failure Handling
• Transient Failure Handling
• Congestion Handling
• Rollback Handling
• Tx Retry Policies
• Traffic Load Balancing

Security

Principles

• Identity Management
• Infrastructure Security
• Application Security
• Contract Security
• Contract Auditing
• Property-based Testing

Best Practices

• Client-side Wallet Integration
• Server-side Key Management
• Node Network Topology
• Plutus Testing Pipeline

Cost Optimization

Principles

• Cost Estimation
• Cost Models
• Cost Monitoring
• Capacity Planning

Best Practices

• Cardano Node Capacity Planning
• DB-Sync Capacity Planning
• Dynamic Scaling

Performance

Principles

• Load Testing
• Stress Testing
• Process Profiling
• Plutus Cost Model

Best Practices

• Mempool Optimization
• Tx Chaining
• Plutus Script Optimization

[Benjmhart]

I'm going to leave some further notes here.

Rollback handling

Yes Please! guidelines on correctly handling a rollback or some assurance that a given indexer will deal with rollbacks automatically would be beneficial.

For me, a well-architected framework would necessarily address issues of Portability & Reproducibility

• we can seamlessly run the app end-to-end on a local, disposable testnet running with less than 32GB of RAM (Even this is probably too much for most development hardware if they are already running Google Chrome and VSCode) without the use of emulation.
• we can also seamlessly run the app on a public testnet or on mainnet.

Though admittedly, Light wallets currently don't support this kind of behavior. Otherwise we are very close.

[Benjmhart]

I would also say that build time and tight feedback loops are key to such a framework.

[Benjmhart]

@scarmuega Are you proposing that we work to build such a framework?

What would our path to success look like?

Lets discuss at the meeting Nov 15

[scarmuega]

@Benjmhart I agree with all of the points mentioned in your previous comments. I'm going to try to paraphrase the background of the ticket as discussed in previous meetings.

Development teams need to make architectural decisions when designing a dApp. Some examples:

• should I use Plutus validators or is it multi-sig enough for my use-case?
• should I balance transactions on the backend or the frontend?
• should I wait for N confirmations before assuming a Tx is done? When do I notify the user?
• how should I protect private keys used in backend processes?
• how should I compensate my dApp state when I detect a rollback?
• how do I univocally identify a user of my dApp? by address? by stake address? signup?
• should I rely on external infrastructure? or use my own?
• how do I load balance nodes? how much load can I add to each node?
• what are the most common attack vectors in a dApp?
• how do I monitor performance?
• can I implement continuous integration for my dApp?

... and the list goes on.

Within the context of this issue, framework refers to a set of principles and best-practices, not necessarily tied to any particular source code or binary (other than those used for reference / example), that could help developers answer questions such as the above.

I think that a path to success would entail:

• defining a comprehensive table of contents for the framework
• gathering principles and best-practices from experienced actors
• documenting the findings in a cohesive format
• implementing a procedure to keep the framework updated as the protocol evolves

[aleeusgr]

discuss how this work aligns with
https://github.com/input-output-hk/cardano-engineering-handbook