njgheorghita

devp2p

Components

• Distributed Peer Table (DPT) / Node Discovery
• RLPx Transport Protocol
• Ethereum Wire Protocol (ETH) / Application Layer

RLPx v4

• v4 is currently the most widely used - (besides LES which uses v5)
• v5 adoption is coming soon (check felix lange's devcon video below)
• This summary based on geth implementation (~ 70% of ethereum nodes)

njgheorghita

Ethereum (public)

Pros

• Best community / Most developed
• Can support a decentralized VRS

Cons

• HDA is probably not cool about a decentralized VRS

Quorum (private)

Pros

• EVM based (uses Solidity/Ethereum smart contracts)

njgheorghita

OPTIONS TO DISPLAY BLOCKCHAIN ACTIVITY

Etherscan

• Will show you tx receipt for any tx sent to a contract address
• Won't show you the current state of the contract - just a history of the txs sent to it and data abou those txs
• You can click on an individual tx to get more information about it
• rinkeby.etherscan.io/address/<put_contract_address_here>
  • i.e. https://rinkeby.etherscan.io/address/0x83ab93d00b2f57baa20be99d560c7025d12dd396

Remix IDE

njgheorghita

Does this project need the blockchain** ?

** I use the term blockchain here to also include DLT (Distributed Ledger Technology) like Corda and HyperLedger Fabric

Do the business process improvements from implementing blockchain provide at MINIMUM 10x - 100x benefit over using traditional technology (cutting costs - improving speed - etc) ?

• The complexity of working with this technology is often underestimated, it can be an arduous and buggy process. especially when integrating with existing systems. Unless the "trustlessness" of a blockchain/dlt generates this 10x - 100x benefit, it's better to opt for traditional tech stack.

I would say - with the complexity of this system [manufacturers, wholesalers, and VRS's working together], the data, speed, and *** a requirement *** to collaborate with many different parties the amount of data flowing around - It’s not guaranteed that blockchain/dlt provides this 10x-100x benefit.

njgheorghita

stand-alone-pkg-with-inheritable-contract

package contains base contract(s)

i.e. owned

• manifest_version
• version
• package_name
• meta
• sources
  • "./contracts/owned.sol": "ipfs:// . . ."

njgheorghita

MVP V1

Deliverable: Interact with any of the 8 contract types deployed on Escape V1.

As a user, who knows the name of a package, it's registry, and version (optional), 
I want to be ableto use this information to interact with the packaged contracts via web3 
(either by deploying new instances, or interacting with existing instances).

njgheorghita

Package Specification

This document defines the specification for a Package. The Package JSON document provides metadata about itself and in most cases should provide sufficient information about the packaged contracts and its dependencies to do bytecode verification of its contracts.

Guiding Principles

The Package specification makes the following assumptions about the

njgheorghita

@contract

owned.sol

@title

owned

@dev

The owned contract stores an 'owner' address, and provides a modifier for basic authorization control functions

njgheorghita

- # Solidity source code
- contract_source_code = '''
- pragma solidity ^0.4.21;
-
- contract Greeter {
-     string public greeting;
-
-     function Greeter() public {
-         greeting = 'Hello';

njgheorghita

Keybase proof

I hereby claim:

• I am njgheorghita on github.
• I am nickghita (https://keybase.io/nickghita) on keybase.
• I have a public key ASDhbClEqb1E2aStPRl4I3AhF4DidSIlqOBSBx9a4_QxTAo

To claim this, I am signing this object: