-
Notifications
You must be signed in to change notification settings - Fork 25
2018 06 02 @ 2pm UTC
Tim McHale edited this page Jun 18, 2018
·
1 revision
- Focus on simplicity of deployment
- Coordinate with Tim on vagrant/terraform approach
- Research protobuf
- Which technology should we use to write APIs?
- Google protobuf? (compressed/efficient)
- TCP sockets?
- How should information be passed from state into transactions... and back again?
- Possible system-call approach
- allows interface with gvisor
- Possible "angles of attack" for this project
- Similar to HLF
- Code runs in Docker
- Spins up external Docker - external execution server
- Don't have more than one node running on one machine
- 5 containers - in each container is a node
- Each node has to spin up container to run chain code
- Vagrant/VirtualBox way of doing things
- Then run terraform
- Docker inside VirtualBox
- Docker Service
- Vagrant to AMI compatibility layer...?
- No Docker -> AMI compatibility
- AWS has a container registry and runner...
- Is Vagrant -> AMI hacky? Robust?
- Terraform - designed to deploy to AWS/rackspace/Google/Azure
- Manages and controls VMs
- Vagrant is the actual VM layer definition
- Build application in Vagrant
- Use Terraform to manage the deployment
- Put in Azure/AWS/rackspace
- Core devs - using Ansible
- Developer-friendly approach
- Some questions about getting access to GPU via Vagrant/Docker
- Discussion around secure execution environment
- Just run Node.js and/or Python
- Trusted Execution Environments - TEE
- Summary, possible angles of attack:
- Vagrant VMs with Docker inside (terraform cloud formations) - possible
- Docker in parallel to each Dockerized sdk - possible
- Docker inside Docker - prob won't work - very hacky...
- just run Node.js or Python... - meh
- Isolated/sandboxed execution environment inside Docker - May not be flexible enough
- mirror what core dev team is doing with Ansible?
- Trusted Execution Environments (TEE)
- Similar to HLF
- Definitely use Fabric as inspiration
- 4/5 instances
- validator node/ordering service?
- One CA, a bunch of peers, run multiple peers
- Tim is already looking at this
- At this stage, prioritise looking at Vagrant/terraform way of doing things.
- Plus looking at execution Docker in parallel to Docker service...
- Need protocol for passing execution request to/from. Eamonn Hynes to look at this.
- Maybe the right answer is:
- Vagrant with multiple Docker images inside of it
- Configuration inside config.txt
- Had to look into compiled code to figure out why it didn't work
- Created an app...
- Started to get into debug mode...
- Alex got 150k-200k/sec tx rate in his Docker sdk
- One of the things Alex can do as a POC - quickly write some golang implementation of interface from Fabric.
- To plug-in custom consensus algorithm...
- Not in the traditional sense of consensus algorithm.
- Cryptographical.
- No BFT algorithm in Fabric right now - They have some JIRA ticket to do that.
- Not sure what version of BFT they want. Not even sure if it will be done this year.
- A POC that will quickly launch a Docker container of hashgraph along with Docker containers of Fabric and composer.
- Allows some chaincode seamlessly on top of Hedera network.
- This is the shortest route to running chaincode on hashgraph.
- That also gives us out of the box - smart contracts.
- Chaincode running on top of hashgraph.
- Written entire platform with modularity in mind.
- One of the things documented there is (first solution that's proposed).
- Implementing interfaces.
- Ensure the Fabric can send the transaction, commit the transaction, handle transaction, implementable,
- A friend of Alex is a very good back-end engineer
- Java Scala and other languages.
- Used in enterprise dev. Very good devops engineer.
- A guy who likes to write network configs in Docker.
- Continuous deployment/delivery.
- Optimised Dockerize of instances.
- Can run composer, hyperledger composer
- Our goal is to "run chaincode"
- It would take a long long time to implement something equivalent to hyperledger.
- Robust and secure. Implemented efficiently and extensible, etc. pooly written code. Full of hardcoding. Full of bugs.
- Experience of writing enterprise grade.
- Ken totally fine with this approach.
- Probably the best place to put hashgraph/sdk in was at orderer layer - 100% pluggable.
- Still be valuable to build all the other stuff.
- A lot more to Fabric than just ordering.
- Must faster if we could just bootstrap off of Fabric - standardised pluggability.
- As opposed to hacking the Fabric code.
- protobuf
- how you build your message is how you sign it
- JSON parsers may not guarantee ordering!!!
- Contractual interface - entire structure.
- protobuf should enforce this.
- It is a contract language!
- Need certainty that whatever we pass in will always be prepared and signed the same way.
- How do we get this all deployed into a real environment?
- Hedera
- Testnets - very limited access
- Next week - more robust!
- API - TCP connection (i.e. socket). As long as you have currency in wallet, you can make a request. Hedera Faucet... Genesis account!
- DAs have been playing with the testnet for a couple of weeks now
- Over next month or two - letting more people into testnet
- Later in summer - open up to the public
- All very exclusive for the next month or two...
- Early stage testnet. Very exclusive list we have to work through
- Who's gonna get earlier access to testnet?
- People we've trusted. And have a close working relationship with. And will actually use it.
- 3 different users categories:
- end user (app user/wallet holder)
- developers
- companies (users or have developers)
- Testnets - very limited access
- Registration process - will be a bit different...
- Definitely going to be having company registration
- Setting up a registration interface for developers/companies/users
- Monday or Tuesday - No! Maybe end of month... registration page
- Hedera account management interface
- Register your public keys, track progress on testnet, get access to testnet
- Ability to define distributed apps. Register on app store.
- Registration step
- Marketplace step
- Possible testnet reward model:
- Historically: Token distribution - model. You give me money and I give you tokens.
- You use our testnet and we give you real live tokens on the mainnet.
- The more you do valuable things on testnet, the more credit you get.
- The bigger chunk of token distribution you get.
- Testnet is gonna get hammered.
- Hammered by people who did KYC/AML.
- One account for your identity.
- You can use this account for everything.
- Will eventually become anonymous testnet in future...
- Criteria - for every smart contract that gets x number of unique executions - x credits
- x number of transactions on network - you get x credit
- Your portion of total volume of transactions on network
- Time windows
- Not so strict right now.
- Just want people to write apps and get people using them.
- Thresholds on how you get tracked for credit (compensated?)
- A little bit harder to get users who are registered to use your app.
- The more you use it, the more you get.
- If you use your tokens, you get more tokens on the network.
- Whole bunch of testnets
- Build SDKs and APIs on top of it
- Guys who engineered this - inspired by Ethereum
- Refine API a bit. Some things they've got ideas about
- People who know how to access these APIs know how to respond
- Indexed array approach - not very excited about?
- What content do we need in this array?
- Ethereum can't do i) in one transaction, execute a multi-sig transaction.
- In Ethereum, each particpant has to execute against
- Alex is sick :( - Get well soon Alex!
- Tim is also under the weather
- Vagrant & Terraform approach (Tim)
- Execution Docker in parallel to Docker Service
- Protocol for passing execution request to/from (Eamonn)
- Eamonn Hynes - Northern Ireland - Allstate Corporation
- Alex Males - Romania
- Craig Drabik - TxMQ - DLT - Hyperledger + EXO project
- Ken Anderson - Hashgraph - Chief Developer Advocate