# Substrate for Beginners
Substrate is one of the most flexible SDK's to create powerful blockchains. It's framework provides full customizability to users in a secure and control enviroment, allowing for innovation to take place.

On the other hand, blockchain technology is still very new and difficult to grasp entirely. Full customizability of a Blockchain SDK is as powerful as it is overwhelming for developers not very experienced in the space.

The following is an attempt of starting a discussion of what the most basic version of Substrate could look like. It should feel like doing `npx create-react-app my-app`, where you can leverage the full power of Substrate, but you can also spin a a project fast. As a [reference from the past](https://web.archive.org/web/20200808231710/https://substrate.dev/docs/en/), the inspiration comes into making this visual representation even larger.


## The mental model
This might be very simplistic, but the mental model to think about this is the current case on how ReactJS works today. ReactJS (and for that matter any other framework that came before like Angular too) made it simple for non-experienced developers to develop front-end applications. These, on top, leveraged a fabric of functionality through NPM and third party providers that made it easy to deploy, like Heroku or Netlify.

If developers wanted, they could use ReactJS to go as deep as they wanted to build crazy stuff with it, or they could just use the provided class that ships with it, and build an extremly simple front end application.

## What needs to be delivered
Substrate is the SDK to create a parachain on Polkadot. Polkadot as a network offers two main features for parachain developers: (i) shared security; (ii) interoperability. On top of this, Substrate has a set of characteristics, but one of the most important ones is the ability to upgrade it's runtime without the need of forking the chain. This arms projects with the ability of iterating easily on their products until they find the right market fit.

Having said that, this project should aim to deliver:
1. An easy to use version of substrate, that teams can start from, but that if needed they can go deep into the woods with it.
2. An opinionated configuration of XCM to facilitate interoperability.
3. An easy way of upgrading and migrating state to allow projects to iterate faster on their product development.
4. A front-end that ships with Substrate.
5. A hussle-free deployment and maintainance strategy.

### Easy to use version of Substrate
This version should strip down all the advanced configurations a developer can do to the runtime. However, if needed down the line, this developer can also change these configurations. In particular, the most importants ones are:
- **Weights**. The weights system is a very advanced and powerful concept that Substrate has, however the basic version should ship with an opinionated and conservative default configuration of weights for all function calls.
- **Substrate Primitives**. The usage of `BoundedVec`, `StorageDoubleMap`, when to use which hasing algorithm like `Blake2_128Concat` and the fact that teams should not be using `!panic` on their runtimes, need to be accounted for. A potential idea would be to have a clippy for Substrate that integrates on the major IDEs.

### Default XCM Configuration
Polkadot's bet is for a multichain blockchain world. In this scenario, interoperability becomes one of the most important features.

Currently teams struggle with configuring XCM and doing XCM calls, so basic Substrate should already ship with the XCM pallet with an opinionated configuration of it.

### Easy product iterations
Thanks to a smart usage of Wasm, Substrate can offer forkless runtime upgrades. This means that the logic of the parachain can evolve to meet the needs of the project. However, this is cumbersome at the moment: runtime upgrades are not easy, PoV needs to be accounted for, and Storage Migrations are hard to do right. Ideally, this beginner version of Substrate would come with tools and limits on what an upgrade means and the way of executing it.

### Front end
A very simple front-end application that uses either CAPI or PolkadotJS as the layer between the basic runtime. The CLI when triggered with the correct flags should build the runtime, the client and the front-end app, and deploy all of them.

### Deployment
There should be a service by which teams can upload their information and have the system deploy automatically their chains. Mental model is a netlify for para{chains,threads}.
Whatever deployment system exists, it needs to have a way of syncing the collators with the relay chain. This could be eventually simplified too.

## Special cases
### Migration from Solidity to Polkadot.
Solidity is the most used language to develop logic on Blockchains at the moment. Therefore a special case to consider is a team that currently has a smart contract deployed on an EVM compatible chain, but wants to become a parachain. This team should be able to: (i) very easily and fast launch it's own para{chain,thread}; (ii) have a clear migration path to building natively on Substrate.

A beginner substrate parachain for this case would need to have, on top of the above:
- **Frontier by default.** This will allow teams to deploy their own smart contracts on their own chain.
- **A good interface between Frontier Pallet and Substrate**. As they migrate to Substrate, they need to easily do this.
- **A clear path to migrate to pallet-based logic**. This includes how to build a pallet, and also how to migrate storage from their current EVM based logic, to a future substrate based logic.

### Security as binary. In or Out.
Although not for beginners, on the other side of the spectrum of complexitiy is full flexibility for Substrate Development. This means, for example, the ability for projects to build their own Consensus Algorithms.
The Security provided by Polkadot at the moment is binary: if you are a para{chain,thread}, you can leverage Polkadot's security. If you are not, then you don't get any of it. With this, crazy developed teams that make extreme advanced usage of Substrate and can't currently connect as a Parachain, don't have any security guarantees from the Relay Chain.

The most common cases at the moment of this situation are:
- Teams that build their own Conseunsus Algorithms (using DAG, building file storage chains, etc).
- Teams that want to have faster block finality.