Four Challenges to StarkNet’s Success

Boxing match

tl;dr

  1. Vendor lock-in: difficulty moving away from StarkWare’s ecosystem
  2. System centralization: the Sequencer and the Prover are operated by StarkWare
  3. Steep learning curve: Cairo is hard to learn and the documentation has gaps
  4. Upgradable smart contracts: StarkWare can make changes at any time
Continue reading “Four Challenges to StarkNet’s Success”

Starknet’s Architecture Review

StarkNet's logo

The architecture shown in this article has inaccuracies. Do not use it as a reference until updated (if ever). In the meantime, refer to the official Starknet docs.

tl;dr

  • Starknet’s user accounts (wallets) are implemented as smart contracts.
  • The system has 3 off-chain components (Sequencer, Prover and Full Nodes) and 2 on-chain (Verifier and Core).
  • The current system architecture is able to handle more transactions than Ethereum but with a higher delay for finality.
  • A dual checkpoint mechanism has been proposed to reduce time to finality without compromising cost.
  • An L2 transaction can be on any of these states: NOT_RECEIVED, RECEIVED, PENDING, ACCEPTED_ON_L2, ACCEPTED_ON_L1 or REJECTED.
Continue reading “Starknet’s Architecture Review”

The Three Paths for Smart Contract Scalability

tl;dr;

  • A smart contract blockchain can scale with hardware, with an optimistic rollup or a zk-rollup
  • Solana’s hardware scaling solution suffers from lack of decentralization and sync issues
  • Optimistic rollups (Optimism) rely on off-chain verifiers and has a 6 days finality on L1
  • zk-rollups (StarkNet) submits and verifies validity proofs on-chain increasing security but also data usage of L1
  • Optimistic rollups are cheaper but zk-rollups are more secure
Continue reading “The Three Paths for Smart Contract Scalability”