solidityResources.md

Smart Contracts that we use

• TF Sale Contracts
• TF Token Contracts
• TF State Machine Framework
• OpenZeppelin Solidity Framework

Documentation, Tutorials & Best Practices

• Solidity Docs

• A Solidity Implementation of the State Machine Design Pattern

• ConsenSys Smart Contracts Best Practices

• Truffle docs/tutorials:

  • Truffle Docs
  • Truffle Tutorials
  • Truffle Debugger

• I'm just learning blockchain development. Where should I start

• Curated resource for Ethreum

• Bare minimum tutorial on deploying smart contracts with python (Optional, we will be using just javascrip)

Code audits

• 0x Protocol v2 Audit
• Gnosis Multisig-wallet Audit
• Leverj audit
• Aragon token audit
• Havven audit

Additional reading material

It is also really important to understand the underlying system when programming smart contracts, so here are a few resources for that:

• Ethereum Whitepaper
• EVM Guide (A little bit outdated)
• Diving into the Ethereum VM
• Awesome Ethereum Virtual Machine
• Ethereum Book

Hyperledger introduction

• Hyperledger Fabric knowledge share: zoom recording

Cryptography lectures by Peter Robinson

• Introduction to Security
• Cryptographic Algorithms
• Cryptographic Algorithms Advanced
• Crypto Terminology

TokenWork Demo Sessions - Mike Goldin talks about TCRs

• Demo sessions list

Cryptoeconomics

• Curated list
• Sample of Prominent Token Designs: Architectures and Cryptoeconomics

Kauri good articles

• Decentralization
• Non fungible tutorial
• Reducing mainnet transactions

Smart Contracts Exploits

• Storage allocation exploit
• List of attacks
• Array overflow attack

Extra solidity tools

• eth-gas-reporter
  • It works only with TF smart contracts tests when it is yarn coverage. The reason is because coverage executes testrpc in a separate process. eth-gas-reporter fails when we use yarn test because Ganache runs in memory.
• Merkle Tree
  • This can be used to build Merkle Tree proofs.

Additional tutorials

• Practical Decompilation of Ethereum Smart Contracts
• Building and installing Ethereum compilers

Ethereum Scaling Solutions

• Summary of Ethereum Scaling Solutions & Teams Working on Them

State Channels

• Alex Miller's Simple Payment Channel
• Jeff Coleman's Overview of State Channels
• Foundations of State Channel Networks
• Generalized State Channels: Includes References to Several Resources
• Machinomy's Medium Articles
• Connext Medium Articles
• L4 Generalized State Channels

State Channel Repos

• Machinomy
• Raiden Network
• Spankchain
• Connext

Plasma

• Plasma Whitepaper
• Alex Miller on Plasma
• Eth Research: Plasma
• Minimum Viable Plasma
• Plasma Cash
• Plasma Implementation Calls

Plasma Repos

• Omisego
• Fourth State
• Leverj

Sharding

Proof of Stake (Casper)

Style Guidelines

• Follow the official Solidity Style Guide

  • Constant variables should be listed in all capital letters.
  • Use succinct, descriptive names for functions and variables.
    • Example: uint256 minContribution versus uint256 num or uint256 contrib
  • For new functions, include a description of the expected functionality and parameters.
  • Write tests for all your code. Use helper functions to make tests as short and concise as possible and use good variable names.
  • Use Solium for Solidity linting.

• For Javascript, use ESlint.

• You can use Git Commands for a quick reference on Git.

Contribution Guidelines

Step 1

• Create a new branch for each card (i.e. task) or relevantly grouped cards (i.e. If several small changes are required as part of a large tasks, please group the changes into one branch.)

• Branch naming should follow the below convention:

  • chore/name-of-branch: To be used for comment, variable name changes, updating compiler versions, or routine updates in general that do not alter the main functionality of the code.
    • Example branch name for adding comments: chore/clarify-comments
  • refactor/name-of-branch: To be used when refactoring existing code.
    • Example branch name for refactoring to add additional require()'s: refactor/add-requires
  • feature/name-of-branch: To be used when adding a new feature to existing code.
    • Example branch name for new feature: feature/add-refund-function
  • bugfix/name-of-branch: To be used when fixing a bug
    • Example branch name for bug: bugfix/fix-reentrancy

• Update Trello to reflect progress (i.e. In Progress).

• If issues arise that prevent you from finishing the task, alert the team in Solidity Slack channel for assistance. If issues continue without resolution, move the task to the Blocked category in Trello to reflect status and put together a plan for resolution or mitigation.

Step 2

• Push changes to your respective branch.
• Pull requests are meant for quick moves to merge.
• If the task includes major design or functionality changes that may require extensive review and potential refactoring, then alert the team in the Slack channel to provide comments on the commit.
• Update any relevant documentation for contract design. This may include: Github docs, google docs, diagrams, etc.
• Once the branch is ready to be merged, open a pull request pointing towards the develop branch, not master.
  • When opening a pull request, add team members for review.
• When reviewing a pull request, leave comments with detailed feedback and ideas for resolution. If questions arise, use the Solidity Slack channel to discuss thoughts.
• Pull requests require at least one approval to merge.

Step 3

• Look to Trello for next available tasks.
• If no available tasks, research advanced Solidity topics relevant to Token Foundry Key Initiatives and put together summaries for the team.