Disclosure, I'm the CEO of Eris Industries
The major difference between the Consensys offering and the Eris Industries offerings on Azure are two fold.
At Eris Industries we are focused as @5chdn rightly noted on being a blockchain-backed application platform. In that regard with eris you can one click install a variety of different blockchains (including ...
Disclosure I'm the CEO of Eris Industries
eris is a blockchain application platform which normalizes many development activities when building a blockchain backed application. It is agnostic as to what the underlying blockchain technology; although admittedly when using some blockchain clients eris provides nominal value beyond configuring, starting and ...
Eris is a services company that targets banks to deploy private blockchains. They employ Ethereum and have forked it but also seem to include some other technology and wrappers that provide additional tools for private companies to leverage blockchains. You can see a lot of Eris' git-hub projects are related to ethereum.
Here is Preston Byrne (Eris Co-...
Microsoft Azure offers a 1-click cloud installation of a full ethereum environment containing a client aswell as the ether.camp integrated developer environment and the blockapps private blockchain environment.
Eris industries develops a free smart contract application plattform. It offers smart contract libraries for subscribers and offers premium features ...
Eris is a cli tool focused on container orchestration for blockchainized applications. Normally we recommend it be installed on the host. It's certainly possible to run from inside docker but it will be much less convenient.
That said, we have images available for eris on quay.io. You can also pull the eris-cli repo and build the canonical dockerfile from ...
Eris-DB essentially is running the EVM combined with Tendermint consensus. This translates to many of the properties that Tendermint has. It can reach finality at ~2 seconds and the block size is variable depending on what you want to put on your chain (Tendermint has some uniqueness in its finality). More can be found here:
Theoretically that would work, practically it likely wouldn't work every well.
We recommend a minimum bound of seven validator nodes with stake distributed amongst the various actors within the network (depending on what the application is trying to achieve). This will allow a tolerance of two nodes to be either malicious or offline at any one time.
The FundManager constructor creates a new Bank contract object...
bank = new Bank();
...and stores its address in this variable:
// This holds a reference to the current bank contract.
When the FundManager's deposit function is called, it calls the Bank contract using its address, as explained in this previous thread:
I think you have to different types of configuration files because:
.yaml file is to configure the smart contracts
.toml file is to configure the blockchain itself with the genesis.json file.
Once the blockchain is running, you can create a miner, and start doploying your smart contracts using the Ether you just mined with your miner.
Edmund Edgar from Reality Keys here.
Reality Keys posts signed data off-chain and you (or a process owned by one of your users) fetch it yourself from our website and send it to your chain. Doing it this way means we don't need the ability to access your blockchain, or indeed need to know that your blockchain exists. This works great with Eris.
If somebody has a node on the network, they can read all the data on the blockchain. There's nothing you can do about this, except stop storing the data unencrypted on the blockchain. You may want to either encrypt each piece of data with the keys of the people who should be able to read it or set up a system to share the data with the appropriate people ...
You can actually do this my running different chains on different ports. This is possible by either using --publish or by using --ports flag. If you use --publish flag then it will randomise the ports. If you use --ports flag then you can specify the ports on which you want to run a particular chain. To read more on ports, use the eris documentation.
Multiple chains running at once on the Eris platform is indeed possible. To do this, for each chain, when you run eris chains new|start, add the --publish flag which will randomize the ports and allow multiple chains to be running at once. Hope this answers your question!
The --compiler flag should be the IP of the compilers service rather than the docker-machine hosts ip.
By default you can omit the flag to use the remote hosted compilers.
Since it looks like you're trying to use the local compiler via the docker image, you can use the --local-compilers flag on version 0.12.0 of eris.
For version 0.11.4, you'll need to ...
To connect the chains, you need to fill in the seeds field in the config.toml file. That field takes a string and the format of the field should be: seedIP1:seedPort1,seedIP2:seedPort2. So if you had three validators running on standard ports with the IPs of 126.96.36.199, 188.8.131.52 and 333.333.333.333 then your seeds field would look like this:
have a look at this demo application. It shows the commands to deploy smart contracts to a Monax (Burrow) chain (monax pkgs do ...) and also contains a NodeJS app to interact with them.
the yaml parser uses (tab) indention very strictly. I think it might be due to the formatting of your .yaml file. It should look like this (have not tried this, yet, but other files work for me).
Also notice the use of function and data when calling the contract (instead of only using the data line containing the function name, which is deprecated).
it seems that the contracts did not deploy correctly, so the application is missing the DealManager smart contract to talk to on the chain. The DealManager entry in the epm.output.json should show an address, if it was deployed successfully.
What was the output of the monax pkgs do ... command? Any errors?
If your question is about geo-location restrictions being a core feature of Hyperledger Burrow, then the answer is no. It is not a current feature; neither is it a planned feature. Burrow is, however, an open source project so you can fork and add that feature on your own.
Enable personal API when launching your node
geth --rpcapi="web3,personal" ....
You can create new account this way. Take a look at https://github.com/ethereum/go-ethereum/wiki/Management-APIs#personal
The prior answer regarding the file types is correct.
The TOML format is simpler and is used throughout Eris (Monax) configuration files, e.g. chain configuration or docker image versions (~/.eris/eris.toml).
The YAML format supports the complexity better that is needed to define the "jobs" that are run be the package manager (EPM) for contract deployment ...
The error is self explanatory if you read,
## These formulae were found in taps:
To install one of them, run (for example):
brew install Caskroom/cask/virtualbox-extension-pack
Since Eris is a permissioned blockchain, you will have to make the permission-logic inside your api layer to make it work. Eris is technically a fork of Ethereum with improvements. source. Web3 should work out of the box, but i am not sure whether they internally disabled it or not.
But there is eris-db.js
Parity allows you to select different consensus engines which are not based on Proof of Work, such as Aura (Proof of Authority) or Tendermint (Practical Byzantine Fault Tolerance, experimental). They are also referred to as validator engines, because only defined validator sets are allowed to participate in consensus.
This enables you to run a permissioned ...
First, you need differentiate private blockchain and permissioned blockchain.
You can see here Private vs Permissioned blockchains.
If you want create a private network with Ethereum here (Permissioned blockchain in ethereum).
If you want to create a permissioned blockchain, you use Quorom, Hydrachain or ErisDB.
Eris currently uses Tendermint as a consensus algorithm. It uses a Byzantine Fault Tolerance algorithm which is secure as long as two-thirds of validators are honest. Thus, it doesn't make much sense to use just two nodes. Blockchains in general don't really apply to just two parties, since each node could just fork the chain without too much work.