---
# System prepended metadata

title: 'Development Update #2 : Stage 1 (cont.)'

---

# Development Update #2 : Stage 1 (cont.)


## Project Discovery

In my previous update, I described my research emphasis on ZK-Rollup technology with the lens of L2 scaling and adoption. 

I am utilizing StarkNet as an example of research subject, particularly because their ZK-rollup L2 network supports smart contracts.

My primary concern for blockchain moving forward is its accessibility and usability. User experience must be improved and given greater focus; this is the only way L2 adoption and usage will scale.

### Project Ideas and Continued Research Paths

#### ZK-Rollups with smart contract support
* How are users communicating with the contracts, and how are they receiving and sending information/funds?
    * Right now, in the case of StarkNet and likely most others, it is primarily CLI engagement with the chain. 
    * Once you have the contract set up, there are various commands you may run. Here are examples of commands on StarkNet via the CLI: 
        * get_transaction (returns transaction)
        * tx_status (returns transaction status)
        * call (calls block/ doesn't affect state)
* How are transactions approved/rejected both on L2 and L1?
    * L2 = STARK proofs
    * L1 = Verified on EVM
* Improve technical documentation; create plan and structure moving forward to enhance user experience and overall adoption of the technology

#### Building on L2/StarkNet
* Beyond cryptocurrency. A more general blockchain/smart contract focus that goes beyond wallets and financial transactions.
* Zero-Knowledge Proofs
    * [STARKs vs SNARKs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)
        * STARK : zero-knowledge scalable transparent argument of knowledge
        * SNARK : zero-knowledge succinct non-interactive argument of knowledge

    * [More docs](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-starks/)

#### Patricia Merkle Trees
* Blocks in StarkNet include a list of transactions and a block header. This block header includes a transaction_commitment field calculated using a patricia merkle tree

#### Cairo Language vs. Solidity (are they complimentary, how do they work together, is one better than the other, etc.)
* StarkNet utilizes the Cairo programming language for their smart contracts
* [Cairo for Blockchain Devs](https://www.cairo-lang.org/cairo-for-blockchain-developers/)

Cairo supposedly solves the "expensive" issue with Ethereum.

Process of "The Shared Prover (SHARP)"

* Cairo code executes business logic
* Prover takes the execution trace, "proves" that it's valid (how?)
* Prover sends the proof to the verifier (on-chain)
* The on-chain verifier then writes a "fact registry contract" attesting to validity of the proof
* dApp checks that the "fact" exists
* fin


[Hello, Cairo!](https://medium.com/starkware/hello-cairo-3cb43b13b209) (StarkWare article)

[Cairo + Voting](https://www.cairo-lang.org/from-voting-to-trustless-eth-bridges-via-signature-aggregation/)

Cairo allows you to write "provable" programs. Ideal for scaling on L2.

#### Investigate other smart contract L2 examples that promote scaling with this level of efficiency


## Tooling needed for L2 adoption

Solidity -> Cairo compiling method ([link to Medium article](https://medium.com/nethermind-eth/solidity-on-starknet-terminal-velocity-e8df5f63e010) and [Warp project](https://github.com/NethermindEth/warp) on GitHub)

## More Information

[The Road to StarkNet](https://medium.com/starkware/on-the-road-to-starknet-a-permissionless-stark-powered-l2-zk-rollup-83be53640880)







