I'm attempting to create a private PoA ethereum network and I've been using morden, ropsten and rinkeby for a while. I didn't realize before that network nodes discovery is made by a connection to some bootnodes. Are these nodes central? And thus, isn't it a big decentralization lack?
I mean, if bootnodes are only few and are set at the beginning of a network creation, we can imagine that those nodes are fraudulent (in the sense of pointing to fraudulent BC nodes). No?
Thank's in advance for your replies
Yes, the bootnodes are central, and for the main and test networks are hardcoded in bootnodes.go.
The "enode://" protocol includes the public key as well as the IP address for these nodes, so you're still effectively trusting the Ethereum Foundation, but it should be secure. From there additional peers will be shared with your node.
Some more details on how connectivity works can be found on the wiki here.
Related
Is it correct that everyone can see my source code once smart contract code has been published to blockchain?
Is it correct that everyone can see application's businesss state and information saved in blockchain?
For example, the example below sends a request to blockchain, receives response from blockchain. In this case, can anyone see the source code and business information? The app uses Ethereum blockchain via Solidity.
https://learn.microsoft.com/en-us/azure/blockchain/service/send-transaction
Is it possible to protect source code and users can only see business states via UI? like conventional web applications.
Smart contract state and any information stored in the blockchain is visible to all observers outside of the blockchain, even local and private variables. (It is not necessarily visible to other smart contracts).
The solidity source code itself is not stored on the blockchain, only the compiled bytecode, which consist of low-level machine instructions (called opcodes) for the Ethereum Virtual Machine. Although this can't easily be converted back into your source code (i.e. all variable names will be missing), it does reveal information about what your code is doing.
In any blockchain the business info/state is visible to the participants of the blockchain network or consortium. Any smart contract state changes in done via a transaction that is shared between the participants of the transaction. Hence the contents/operations exposed via that smart contract is also visible to the participants of that transaction, so that they can verify it's validity / have a consensus on whether to accept/reject it.
To answer your question "everyone" may not be able to see the contents unless it is a public smart contract / transaction you are dealing with. in case of public transaction/contracts it is visible to that public chain. If it is a private transaction, then it is only visible to the participants of the private transaction.
Reference: Q&A
Next week I'm starting on a new blockchain project using Hyperledger Fabric. I have a question regarding the configtx binary.
We use this binary to create a channel.tx and a genesis.block. I have read the documentation, watched tutorials and looked on the internet but I still don't understand why the genesis.block and channel.tx is needed an why it's created like this. For example: shouldn't the genesis.block be in the blockchain including the channel configuration?
A simplified answer:
A genesis block is referred to as the first block.
The first (genesis) block in a channel, is a channel.tx (channel configuration transaction). It doesn't contain much more than the name of the channel, and the consortium that is allowed to use the channel.
The orderer genesis block is what configures an orderer when it starts. It contains MSP IDs for each organization, which MSP IDs are part of a consortium, and a trusted certificate for each MSP ID.
The orderer needs information about organizations, because the orderer approves the creation of new channels. A channel creation request must come from a trusted entity (part of an organization), or else the channel will not be created.
Since you cannot modify (execute a transaction) in a channel without an orderer approving, it makes sense to only let the orderer have the network information. This way you don't risk having inconsistent information between channels/orderers in case anything changes.
All Fabric blocks are encoded/serialized using protobuf, as the internal communication relies on gRPC. A block is thus in a binary format.
Think like this, what would you do if you want to change the configuration of the blockchain system? shutdown all the host, edit their config and restart them one by one? That will be rediculous, because we say that blockchain is decentralized, nobody can control all the hosts. The only way to change configurarion dynamically is consensus online. So how to make consensus online, obviously, the answer is using transactions(tx). As for the initialization of the blockchain in frabric, we can use the same way , that is channel.tx and genesis.block, to eliminating the cost of initialization by reuse the logic of editting configuration. Meanwhile, tx should be placed in a block, so that is why genesis.block exist.
I created a genesis.json file - private network(Ethereum).
for some reason, I want to allocate new ETH to new Addresses(like I did before at the genesis file).
my question:
if I change the genesis file and re-create the network, are all the eth that transferred to other wallets will be lost? (all the database will be lost?)
OR
there is a way to dynamically upgrade the genesis.json file?
if there is a way in the PoA/PoS/PoW Ethereum network please let me know
You can't.
The genesis.json describes the chain state at the beginning. Once blocks are mined on top of this chainstate, it cannot be altered, or it would render the entire chain (all the blocks) invalid, and you would be on a brand new network.
In a PoA network, you are supposed to pre-allocate as much ether as required, and use regular transactions to send that to new addresses as needed. It is a good idea to overallocate at the start, and set up a faucet system to make distribution easier.
I've seen/heard developers talk about Ethereum test nets, but I've just been publishing to the public block chain. What is a private test net and how do I set one up?
A private testnet is your own personal, local-to-your-machine blockchain to mess around with. Publishing to the public chain is slow and creates bloat. Plus, you have to use real ether to do anything. A private test net avoids these issues.
Setting up a private testnet is easier than you’d think.
geth --rpc --rpcaddr "127.0.0.1" --rpcport "8545" --dev --mine
This says, “start a geth instance with JSON RPC (for web3.js interaction) at the given IP and port, create a private chain and start mining it.” In the log, you should see lots of the hammer icons, signifying that you’re mining your private chain’s blocks. (CPU-only mining is sufficient because the difficulty begins so low.)
When you type “geth attach” per usual in another terminal window, you’ll see that all of your accounts balances are zero except your coinbase which is rapidly filling up with fake ether. Don’t worry. Your accounts aren’t really zero. All their “real” values will be there if you connect to a “real” geth instance and the public blockchain.
Now you can interact with your private test net just as you would the public one.
A diffrent way to setup a private Network is to use testrpc. This kinda simulates a ethereum Network by providing a local client that acts as if it is connected to a network for development and testing. The advantage is, that it is very fast, but it will not presist the state of your network as it operates completely in memory.
I'm receiving a recovery feed from an exchange for recovering data missed from their primary feed.
The exchange strongly recommends listening to the recovery feed only when data is needed, and leaving the multicast once I have recovered the data I need.
My question is, if I am using asio, and not reading from the NIC when I don't need it, what is the harm? The messages have sequence numbers, so I can't accidentally process an old message "left" on the card.
Is this really harming my application?
It's likely not harming your application so much as harming your machine - since the nic is still configured into the multicast group, it's still listening to those messages and passing them up, before your software ignores them and they get discarded. That's a lot of extra work that your network stack and kernel are doing, and therefore a lot of extra load on the machine in general, not just your app.
Listening to your recovery feed could also have a potential impact on a network level. As pjz mentioned, your NIC and IP stack will have more frames/packets to process. In addition, more of your available bandwidth is being used up by data that is not being used by your application; this could lead to dropped frames if there is congestion on your link. Whether congestion is likely to occur depends on whether your server is 100Mb or 1Gb attached, how much other traffic your host is sending/receiving, etc.
Another potential concern is the impact on other hosts. If the switch your host is attached to does not have IGMP snooping enabled, then all hosts on the same VLAN will receive the additional multicast traffic, which could lead them to experience the same problems as mentioned above.
If you have a networking team administering your network for you, it may be worth seeking out some recommendations from them? If you feel it is necessary to subscribe to a redundant feed, it would seem prudent to work out what level of redundancy already exists in your network and how likely it is that messages on the primary feed will be lost.
An addition to muz's comment...
It's unlikely that this will make any difference to your system, but it's worth being aware that there is an overhead associated with maintaining a multicast membership (assuming that you're using IGMP - which is probably reasonable given the restriction about "leaving the multicast")
IGMP requires the sending and processing of multicast group memberships at regular intervals. And (as alluded to in muz's comment) if you have any switches or routers between you and the multicast source that are capable of igmp snooping then they are able to disable the multicast for a given network.