Triple-Entry Bookkeeping: How Satoshi Nakamoto Solved the ...

Best General RenVM Questions of April 2020

Best General RenVM Questions of April 2020
\These questions are sourced directly from Telegram*
Q: Quick question here, but any plan to bridge as well with the Tezos protocol? Using soon to be released Ren network could be a key advantage to be the first with a viable solution on their protocol. Plus Ren is indépendant of ETH (collateral speaking) making it interesting for other protocols.
A: Yes, this is very much possible. RenVM can work with any ‘destination chain’ that has smart contract functionality. We’ll be exploring others like Polkadot, Tezos, etc.. once it makes sense and we are happy with the Ethereum side of things.
Q: How many physical Darknodes will be in Greycore?
A: It depends on the final cohort, but it’ll be 15+ as each team will run a few Darknodes. Even the Greycore, our most “centralized” part of RenVM (at first) will be more decentralized than all competitors. Also, it is not so important the number of nodes as it is the number of members. More nodes = more architectural decentralization, but not more political decentralization. That is, more fault tolerance, but not more Byzantine fault tolerance.
Q: Once RenVM gets going, is there a way to measure cross-(on)chain volume?
A: We’ll be measuring any/all volume that flows through RenVM. This info will be available in the new Command Center (CC), GraphProtocol, etc.
Q: What is the reasoning for disabling auto-updates for Darknodes? Will operators get to choose if auto updates are allowed or not?
A: Auto updates of things that control funds is generally a bad idea. Someone could poison the repo you’re using for updates and you’d have no control. Further, disabling auto-updating means that governance is in the hands of the Darknodes, albeit in a very ad hoc way (excluding the smart contracts on Ethereum).
Q: I know you have addressed this before, but here’s a discussion about ren’s ability to mint renBTC being limited by its public market cap. I think the team is coming up with a way to have the Darknode capacity determined by Darknodes based on revenue rather than the price of ren right?
A: This design is one of RenVM's biggest comparative advantages over other designs. The value of REN (as calculated by Darknodes) and thus RenVM's capacity are directly tied to usage of RenVM. The more renBTC minted/burned, the greater Darknodes' revenues, the higher value of REN, the greater capacity to mint more. It's a positive feedback loop where increased usage increases capacity. To your question, the "3" in L<3 will be calculated by Darknodes strictly by revenues, not by a potentially manipulable oracle. Although this may be a soft cap in Zero and One with Greycore secondary sigs and continuous fees.
Conversely, tBTC's bond is overcollateralized by ETH, which is uncorrelated to usage of tBTC. Because the price of ETH does not increase with usage of tBTC, increased usage of tBTC will require more and more ETH to stay overcollateralized. As the article says, just 1% ($1.34B) of BTC's market cap ($134B) in tBTC would require $2.01B in bonded ETH, which is 10% of all ETH. 5% of BTC in tBTC, 56% of ETH.
A bond whose value is tied to usage of its own network allows capacity to scale linearly.
Further: Collateral is not the problem. Any technique that anyone uses to reduce collateral should be usable by any system doing interop. The real difference is that RenVM using its own token, so it is able to adjust its own economic parameters, and it does not need liquidation which we have seen fail as recently as last month.
-Use RenVM => REN worth more => higher cap => can use RenVM even more
-Use tBTC => ETH fluctuates independently => liquidations can occur => node operators get liquidated => can use tBTC less
RenVM is much more capital efficient in the long-term, regardless of the specific collateral ratios required. It also doesn’t expose Darknodes to ETH risk (and even renBTC holders, if renBTC could sometimes only be reclaimed for ETH not actual BTC, like it systems with liquidation).
Lastly, it has a bunch of practical defenses, like constantly shuffling its Darknode shards (instead of them sticking around for up to 6 months). And we have some nice UX features, like being able to move any amount of BTC at any time, straight into a smart contract call.
Q: https://preview.tbtc.network/cms/resource/tbtc-security-model/developers/tbtc-security-model/. At the end of the article Ren's security model is briefly discussed, is this correct?
A: For the record, that is an incorrect summary (either through not being sure how things works, or in an attempt to discredit our security model). RenVM is not a federated peg. Our shards are designed to have up to ~200 nodes in them. tBTC has three (3). Seems the latter is a lot closer to a federation than the former.
Q: So RenVM can run on Binance chain instead of Ethereum? Or what would be the advantage (or goal)? Pls eli5. A: RenVM doesn’t run on any chain; it is its own network. However, it has host chains which are chains to which it can send assets. For example, you can send BTC to Ethereum, and in this scenario Ethereum is the host chain (it is hosting a non-native asset). Supporting Binance Chain would imply that RenVM can use it as another host chain.
Q: If another host chain is implemented, would cross-host chain transactions be possible without doing any transactions with the token. Like: Bitcoin -> renBTC_ETH -> renBTC_BNB
Without an intermediate step, and without paying Bitcoin transactions on the Bitcoin network. Unlike: Bitcoin -> renBTC_ETH -> Bitcoin -> renBTC_BNB
A: Yep. A burn event would be generated on one host chain, and RenVM would produce a minting signature for the other host chain. No BTC moves on the Bitcoin chain, so no Bitcoin fees would be required. RenVM would still take a fee though.
Q: Reading about sharding in the docs: it mentions load balancing. Would that be done on a monthly basis as the changeover in keys is done?
A: At minimum, once per epoch.
Q: I'm sure there were discussions about this before but I can't find anything on it. Is there a possibility where assets in custody in REN network could be greater than 1/3 of value of REN tokens and have the network still be secure? Or is this a big no no that the network will have to do everything for the 1/3 threshold not be crossed ?
A: It’s not a big no no, it is still well collateralized at that point. However, it is a no no. 1/3rd is the limit above which an attack becomes theoretically profitable. It is still not practically profitable at that stage, and is also very difficult to actually pull off such an attack. So RenVM must aim to keep under 1/3rd, but if that threshold is crossed nothing bad happens immediately (this gives some time for fee adjustments that should have already been put in place by this point to kick in).
We’re also looking at some proposals internally around how to recover the peg even if an attack does succeed (because 1/3rd is crossed by enough, and for long enough, that a profitable attack succeeds, or because an irrational attacker has decided to attack without the want for profit).
That’s correct. We class these actors as “irrational adversaries”. This is an attacker that doesn’t care about the profitability as modelled by the protocol. It’s important to be able to resist such adversaries because, as you point out, there are adversaries that can achieve be profit from RenVM in a way that cannot be feasibly modelled.
Q: How many hours can my VPS be down before it's Deregistered (not shalshed)?
A: 12 hours. We’ll use Mainnet Subzero to establish parameters and change the thresholds if needed.
Q: Which VPS provider (for Darknodes) is next?
A: Azure is the next one on our list of VPS’s to support.
submitted by RENProtocol to RenProject [link] [comments]

Cosmos — an early in-depth analysis at the ecosystem of connected blockchains — Part One

Cosmos — an early in-depth analysis at the ecosystem of connected blockchains — Part One
This is part one of three articles where i will discuss what i have learnt whilst looking into Cosmos. I will provide links throughout the article to provide reference to sections as well as a list of sources at the bottom of the article for you to look into specific areas in more detail if required. Hopefully it will be useful for those interested in learning more about the project.
Cosmos is still very early in development process with components such as IBC which connects two blockchains together currently in research / specification stage, as a result can change by the time its released.

What is Cosmos?

Cosmos is a network and a framework for interoperability between blockchains. The zones are powered by Tendermint Core, which provides a high-performance, consistent, secure PBFT-like consensus engine, where strict fork-accountabilityguarantees hold over the behaviour of malicious actors. Cosmos is not a product but an ecosystem built on a set of modular, adaptable and interchangeable tools.
In Tendermint, consensus nodes go through a multi-round voting proposal process first before coming to consensus on the contents of a block. When 2/3 of those nodes decide on a block, then they run it through the state transition logic providing instant finality. In current proof of work consensus for Ethereum, the consensus process is inverted, where miners pick the transactions to include in a block, run state updates, then do “work” to try and mine the block.
Tendermint BFT can handle up to thousands of transactions per second (depending on the number of validators). However, this only takes into account the consensus part, the application layer is the limiting factor though. Ethermint (described below) has achieved up to 200 tps to give you an idea of the speed available per blockchain which is significantly more than current versions of Ethereum and Bitcoin etc.
The Tendermint consensus is used in a wide variety of projects, some of the most notable include Binance Chain, Hyperledger Burrow. It’s important to note though that just using Tendermint consensus doesn’t mean they can connect to other chains with the cosmos ecosystem, they would need to fork their code to implement IBC as a native protocol to allow interoperability through IBC.
see https://raw.githubusercontent.com/devcorn/hackatom/mastetminfo.pdf for high res

The Tendermint consensus algorithm follows a traditional approach which relies on all validators to communicate with one another to reach consensus. Because of the communication overhead, it does not scale to 1000s of validators like Bitcoin or Ethereum, which can have an unlimited number of validators. Tendermint works when there are 100s of validators. (Cosmos Hub currently has a maximum of 100 validators and the maximum tested so far with Tendermint is 180 validators)
Therefore, one of the downsides of a blockchain built using Tendermint is that, unlike Bitcoin or Ethereum, it requires the validators to be known ahead of time and doesn’t allow for miners to come and go as they please.Besides this, it also requires the system to maintain some notion of time, which is known to be a complex problem in theory. Although in practice, Tendermint has proven this can be done reasonably well if you use the timestamp aggregates of each node.
In this regard, one could argue that Tendermint consensus protocol is “less decentralized” than Bitcoin because there are fewer validators, and they must be known ahead of time.
Tendermint’s protocol guarantees safety and liveness, assuming more than 2/3 of the validators’ voting power is not Byzantine (i.e., malicious). In other words, if less than 1/3 of the network voting power is Byzantine, the protocol can guarantee safety and liveness (i.e., validators will never commit conflicting blocks at the same height and the blockchain continues to make progress).https://www.preethikasireddy.com/posts/how-does-cosmos-work-part1
To see the process of how Tendermint works please see this diagram as well as more info here

Sovereignty

Cosmos goal is to provide sovereignty through governance to developers by making it easy to build blockchains via the Cosmos SDK and provide interoperability between them, using Tendermint consensus. This is their main differentiator compared to competition like Polkadot and Ethereum 2.0. Ethereum 2.0 and Polkadot are taking a different approach by only using shared security, where there is a root chain which controls the security / prevents double spending for all connected blockchains.
In Hub governance all stakers vote, the validators vote is superseded if the delegator votes directly
Governance is where all stakers vote on proposals to determine what changes are implemented in the future for their own blockchain, stakers can either choose to delegate their vote to the validator or they can instead vote directly. Without sovereignty all DAPPs share the same underlying environment. If an application requires a new feature in the EVM it has to rely entirely on the governance of the Ethereum Platform to accept it for example. However, there are also tradeoffs to having sovereignty as each zone is going to need a way to incentivise others to validate / create blocks on the Zone by running Full Nodes. Whilst it may be easy to create a blockchain using the cosmos SDK and to mint a token, there are the legal costs / regulation associated with creating your own token. How are you going to distribute the tokens? How are you going to list them on exchanges? How are you going to incentivise others to use the token without being classed as a security? All of which have led to a significant reduction in the number of ICOs being done. With every zone needing their own validator set, there’s going to be a huge number of validators required each trying to persuade them to validate their zone with only a finite number of validators available.
Each Zone / App is essentially a mini DAO and not all are going to be comfortable about having their project progress been taken out of their hands and instead relying on the community to best decide on the future (unless they control 2/3 of the tokens). The Cosmos Hub has proved this can be successful, but others may be risk averse to having their application be a mini DAO. Should someone / competitor acquire 1/3 of the tokens of a zone then they could potentially prevent any further progress being made by rejecting all governance votes (this would be very costly to do on the Cosmos Hub due to its high amount staked, but for all the other less secure zones this potentially may be an issue).
Security for some zones will likely be a lot lower with every developer needing to validate their own blockchain and tokenise them with POS with no easy way to validate the setup of a validator to ensure its secure. Whilst the Cosmos hub is very secure with its current value staked, how secure zone’s will be with significantly less staked remains to be seen. Whilst providing soverignty was Cosmos’s main goal from the start, they are also looking at being able to provide shared security by having validators of a connected Hub also validate /create new blocks on the connected zone’s blockchain for them as well. They are still going to need some way to incentivise the validators to this. Another option is if the developers didn’t want to create a token, nor want sovereignty etc, then they could just build a DAPP on the EVM on a zone such as Ethermint.
As can be seen their are potential advantages and disadvantages to each method, but rather than forcing shared security like Ethereum and Polkadot, Cosmos is giving the developer the choice so will be interesting to see which they prefer to go for.

Layers of a blockchain

From an architecture standpoint, each blockchain can be divided into three conceptual layers:
  • Application: Responsible for updating the state given a set of transactions, i.e. processing transactions.
  • Networking: Responsible for the propagation of transactions and consensus-related messages.
  • Consensus: Enables nodes to agree on the current state of the system.
The state machine is the same as the application layer. It defines the state of the application and the state-transition functions. The other layers are responsible for replicating the state machine on all the nodes that connect to the network.
The Cosmos SDK is a generalized framework that simplifies the process of building secure blockchain applications on top of Tendermint BFT. The goal of the Cosmos SDK is to create an ecosystem of modules that allows developers to easily spin up application-specific blockchains without having to code each bit of functionality of their application from scratch. Anyone can create a module for the Cosmos SDK and using ready built modules in your blockchain is as simple as importing them into your application.
The Tendermint BFT engine is connected to the application by a socket protocol called the Application Blockchain Interface (ABCI). This protocol can be wrapped in any programming language, making it possible for developers to choose a language that fits their needs.

https://preview.redd.it/5vpheheqmba31.png?width=770&format=png&auto=webp&s=ec3c58fb7fafe10a512dbb131ecef6e841e6721c

Hub and Spoke Topology

Cosmos follows a hub and spoke topology as its not feasible to connect every zone together. If you were to connect every blockchain together the number of connections in the network would grow quadratically with the number of zones. So, if there are 100 zones in the network then that would equal 4950 connections.
Zones are regular heterogenous blockchains and Hubs are blockchains specifically designed to connect Zones together. When a Zone creates an IBC connection with a Hub, it can automatically access (i.e. send to and receive from) every other Zone that is connected to it. As a result, each Zone only needs to establish a limited number of connections with a restricted set of Hubs. Hubs also prevent double spending among Zones. This means that when a Zone receives a token from a Hub, it only needs to trust the origin Zone of this token and each of the Hubs in its path. Hubs do not verify or execute transactions committed on other zones, so it is the responsibility of users to send tokens to zones that they trust.
There will be many Hubs within Cosmos network the first Hub to launch was the Cosmos Hub whose native staking token is called ATOM. ATOM tokens are specific to just the Cosmos Hub which is one hub of many, each with their own token. Transaction fees for the Cosmos Hub will be payable in multiple tokens so not just ATOMs whereas other Hubs such as IRIS has made it so that all transaction fees are paid in IRIS for transactions on its hub.
As mentioned, the Cosmos Hub is one of many hubs in the network and currently has a staking ratio of around 70% with its token ATOM having a market cap of just over $800 million. IRISnet was the second Hub to launch which currently has around 28% bonded with its token IRIS which has a market cap of just under $17 million. The Third Hub about to be launched later this month has its token SENT which has a market cap of around $3.4 million. As you can see the security of these 3 hubs differ wildly and as more and more hubs and then zones are brought online there is going to need to be a lot of tokens / incentivisation for validators.
Ethermint
Standard Cosmos zones / hubs don’t have smart contract functionality and so to enable this, as the Application layer is abstracted from the consensus layer via ABCI API described earlier, it allows Cosmos to port the code over from other blockchains such as Ethereum and use it with the Tendermint Consensus to provide access to the Ethereum Virtual Machine. This is what is called Ethermint.
This allows developers to connect their zones to specialised zones such as Ethermint to build and run smart contracts based on Solidity, whilst benefiting from the faster performance of the tendermint Conensus over the existing POW implementation currently. Whereas a normal Go Ethereum process runs at ~12.5 transactions per second (TPS), Ethermint caps out at 200 TPS. This is a comparison against existing Ethereum speeds, whilst obviously Ethereum are working on their own scaling solutions with Ethereum 2.0 which will likely be ready around the same time. Existing tools / dapps used on ethereum should easily be able to be ported over to Ethermint by the developer if required.
In addition to vertical scaling (with the increase in tps by using Tendermint consensus), it can also have multiple parallel chains running the same application and operated by a common validator set. So if 1 Ethermint zone caps out at 200 TPS then 4 Ethermint zones running in parallel would theoretically cap out at 800 TPS for example.

https://preview.redd.it/e2pghr9smba31.png?width=554&format=png&auto=webp&s=a6e472a6e4a0f3845b03c36caef8b42d77125e46
There is a huge number of developers / apps currently built on Ethereum, should a developer choose to migrate their DAPP over to Ethermint they would lose native compatibility with those on Ethereum (except through Peg Zone), but would gain compatibility with those running on Ethermint and others in the cosmos ecosystem.
You can find out more about Ethermint here and here

IBC

IBC stands for inter-blockchain communication protocol and is an end-to-end, connection-oriented, stateful protocol for reliable, ordered, authenticated communication between modules on separate distributed ledgers. Ledgers hosting IBC must provide a certain set of functions for consensus transcript verification and cryptographic commitment proof generation, and IBC packet relayers (off-chain processes) are expected to have access to network protocols and physical datalinks as required to read the state of one ledger and submit data to another.
In the IBC architecture, modules are not directly sending messages to each other over networking infrastructure, but rather creating messages to be sent which are then physically relayed via “Relayers”. “Relayers” run off-chain and continuously scan the state of each ledger via a light client connected to each of the 2 chains and can also execute transactions on another ledger when outgoing datagrams have been committed. For correct operation and progress in a connection between two ledgers, IBC requires only that at least one correct and live relayer process exists which can relay between the ledgers. Relays will need to be incentivised to perform this task (the method to which hasn’t been established as of this writing)
The relay process must have access to accounts on both chains with sufficient balance to pay for transaction fees. Relayers may employ application-level methods to recoup these fees, such by including a small payment to themselves in the packet data. More information on Relayers can be found here

https://preview.redd.it/qr4k6cxtmba31.png?width=1100&format=png&auto=webp&s=d79871767ced4bcb0b2632cc137c118f70c3863a
A high-level overview of the process is that Zone 1 commits an outbound message on its blockchan about sending say 1 x Token A to Hub1 and puts 1 x Token A in escrow. Consensus is reached in Zone 1, and then it’s passed to the IBC module to create a packet which contains the reference to the committed block, source and destination channel/ connection and timeout details and is added to Zone 1’s outbound queue as proof.
All relayers (who run off-chain) are continuously monitoring the state of Zone 1 via the Zone 1 light client. A Relayer such as Relayer 1 is chosen and submits a proof to Hub1 that Zone 1.
Hub 1 then sends a receipt as proof that it has received the message from Zone 1, relayer1 sends it to Zone 1. Zone 1 then removes it from its outbound queue and sends proof via another receipt to Hub1. Hub1 verifies the proof and mints the token.

https://preview.redd.it/qn7895rumba31.png?width=770&format=png&auto=webp&s=96d9d808b2284f87d45fa0bd7b8bff297c86c2da
This video below explains the process in more detail as well as covers some of the other points i raise later in this article so worth a watch (time stamped from 22:24 to 32:25) and also here from 38:53 to 42:50
https://youtu.be/5h8DXul4lH0?t=1344
Whilst there is an option for UDP style transfer where a zone will send a message to a Hub and it doesn’t care whether it gets there or in any order etc, Token transfers are going to require the TCP style connections in IBC where there is a send, receipt and then another receipt as explained above. Each Send, receipt followed by another receipt is going to take at least 2 blocks and so using Cosmos Hub block times as an example with 6.88 second block times a transfer between one zone and hub could take a minimum of 41.28 seconds. You also then have to factor in the amount of other transactions going through those at that time and relevant gas price to see whether it is able to use 2 consecutive blocks or whether it may take more. This is also explained in this video “ILP Summit 2019 | Cosmos and Interledger | Sunny Aggarwal” (time stamped) from to 12:50 to 15:45

In Part Two we will look at potential issues with multi hop routing, token transfers across multiple routes and Peg Zones, whilst also looking at other interoperability solutions that would resolve some of these issues and compliment the cosmos ecosystem. Part Two can be found here
submitted by xSeq22x to cosmosnetwork [link] [comments]

Cosmos — an early in-depth analysis at the ecosystem of connected blockchains — Part One

Cosmos — an early in-depth analysis at the ecosystem of connected blockchains — Part One
This is part one of three articles where i will discuss what i have learnt whilst looking into Cosmos. I will provide links throughout the article to provide reference to sections as well as a list of sources at the bottom of the article for you to look into specific areas in more detail if required. Hopefully it will be useful for those interested in learning more about the project.
Cosmos is still very early in development process with components such as IBC which connects two blockchains together currently in research / specification stage, as a result can change by the time its released.

What is Cosmos?

Cosmos is a network and a framework for interoperability between blockchains. The zones are powered by Tendermint Core, which provides a high-performance, consistent, secure PBFT-like consensus engine, where strict fork-accountabilityguarantees hold over the behaviour of malicious actors. Cosmos is not a product but an ecosystem built on a set of modular, adaptable and interchangeable tools.
In Tendermint, consensus nodes go through a multi-round voting proposal process first before coming to consensus on the contents of a block. When 2/3 of those nodes decide on a block, then they run it through the state transition logic providing instant finality. In current proof of work consensus for Ethereum, the consensus process is inverted, where miners pick the transactions to include in a block, run state updates, then do “work” to try and mine the block.
Tendermint BFT can handle up to thousands of transactions per second (depending on the number of validators). However, this only takes into account the consensus part, the application layer is the limiting factor though. Ethermint (described below) has achieved up to 200 tps to give you an idea of the speed available per blockchain which is significantly more than current versions of Ethereum and Bitcoin etc.
The Tendermint consensus is used in a wide variety of projects, some of the most notable include Binance Chain, Hyperledger Burrow. It’s important to note though that just using Tendermint consensus doesn’t mean they can connect to other chains with the cosmos ecosystem, they would need to fork their code to implement IBC as a native protocol to allow interoperability through IBC.

see https://raw.githubusercontent.com/devcorn/hackatom/mastetminfo.pdf for high res

The Tendermint consensus algorithm follows a traditional approach which relies on all validators to communicate with one another to reach consensus. Because of the communication overhead, it does not scale to 1000s of validators like Bitcoin or Ethereum, which can have an unlimited number of validators. Tendermint works when there are 100s of validators. (Cosmos Hub currently has a maximum of 100 validators and the maximum tested so far with Tendermint is 180 validators)
Therefore, one of the downsides of a blockchain built using Tendermint is that, unlike Bitcoin or Ethereum, it requires the validators to be known ahead of time and doesn’t allow for miners to come and go as they please.Besides this, it also requires the system to maintain some notion of time, which is known to be a complex problem in theory. Although in practice, Tendermint has proven this can be done reasonably well if you use the timestamp aggregates of each node.
In this regard, one could argue that Tendermint consensus protocol is “less decentralized” than Bitcoin because there are fewer validators, and they must be known ahead of time.
Tendermint’s protocol guarantees safety and liveness, assuming more than 2/3 of the validators’ voting power is not Byzantine (i.e., malicious). In other words, if less than 1/3 of the network voting power is Byzantine, the protocol can guarantee safety and liveness (i.e., validators will never commit conflicting blocks at the same height and the blockchain continues to make progress).https://www.preethikasireddy.com/posts/how-does-cosmos-work-part1
To see the process of how Tendermint works please see this diagram as well as more info here

Sovereignty

Cosmos goal is to provide sovereignty through governance to developers by making it easy to build blockchains via the Cosmos SDK and provide interoperability between them, using Tendermint consensus. This is their main differentiator compared to competition like Polkadot and Ethereum 2.0. Ethereum 2.0 and Polkadot are taking a different approach by only using shared security, where there is a root chain which controls the security / prevents double spending for all connected blockchains.
Governance is where all stakers vote on proposals to determine what changes are implemented in the future for their own blockchain, stakers can either choose to delegate their vote to the validator or they can instead vote directly. Without sovereignty all DAPPs share the same underlying environment. If an application requires a new feature in the EVM it has to rely entirely on the governance of the Ethereum Platform to accept it for example. However, there are also tradeoffs to having sovereignty as each zone is going to need a way to incentivise others to validate / create blocks on the Zone by running Full Nodes. Whilst it may be easy to create a blockchain using the cosmos SDK and to mint a token, there are the legal costs / regulation associated with creating your own token. How are you going to distribute the tokens? How are you going to list them on exchanges? How are you going to incentivise others to use the token without being classed as a security? All of which have led to a significant reduction in the number of ICOs being done. With every zone needing their own validator set, there’s going to be a huge number of validators required each trying to persuade them to validate their zone with only a finite number of validators available.
Each Zone / App is essentially a mini DAO and not all are going to be comfortable about having their project progress been taken out of their hands and instead relying on the community to best decide on the future (unless they control 2/3 of the tokens). The Cosmos Hub has proved this can be successful, but others may be risk averse to having their application be a mini DAO. Should someone / competitor acquire 1/3 of the tokens of a zone then they could potentially prevent any further progress being made by rejecting all governance votes (this would be very costly to do on the Cosmos Hub due to its high amount staked, but for all the other less secure zones this potentially may be an issue).
Security for some zones will likely be a lot lower with every developer needing to validate their own blockchain and tokenise them with POS with no easy way to validate the setup of a validator to ensure its secure. Whilst the Cosmos hub is very secure with its current value staked, how secure zone’s will be with significantly less staked remains to be seen. Whilst providing soverignty was Cosmos’s main goal from the start, they are also looking at being able to provide shared security by having validators of a connected Hub also validate /create new blocks on the connected zone’s blockchain for them as well. They are still going to need some way to incentivise the validators to this. Another option is if the developers didn’t want to create a token, nor want sovereignty etc, then they could just build a DAPP on the EVM on a zone such as Ethermint.
As can be seen their are potential advantages and disadvantages to each method, but rather than forcing shared security like Ethereum and Polkadot, Cosmos is giving the developer the choice so will be interesting to see which they prefer to go for.

Layers of a blockchain

From an architecture standpoint, each blockchain can be divided into three conceptual layers:
  • Application: Responsible for updating the state given a set of transactions, i.e. processing transactions.
  • Networking: Responsible for the propagation of transactions and consensus-related messages.
  • Consensus: Enables nodes to agree on the current state of the system.
The state machine is the same as the application layer. It defines the state of the application and the state-transition functions. The other layers are responsible for replicating the state machine on all the nodes that connect to the network.
The Cosmos SDK is a generalized framework that simplifies the process of building secure blockchain applications on top of Tendermint BFT. The goal of the Cosmos SDK is to create an ecosystem of modules that allows developers to easily spin up application-specific blockchains without having to code each bit of functionality of their application from scratch. Anyone can create a module for the Cosmos SDK and using ready built modules in your blockchain is as simple as importing them into your application.
The Tendermint BFT engine is connected to the application by a socket protocol called the Application Blockchain Interface (ABCI). This protocol can be wrapped in any programming language, making it possible for developers to choose a language that fits their needs.

https://preview.redd.it/go1bgareiba31.png?width=770&format=png&auto=webp&s=c9a2c9faa9c99dd8c7a7b6925c7ea281e203eb47

Hub and Spoke Topology

Cosmos follows a hub and spoke topology as its not feasible to connect every zone together. If you were to connect every blockchain together the number of connections in the network would grow quadratically with the number of zones. So, if there are 100 zones in the network then that would equal 4950 connections.
Zones are regular heterogenous blockchains and Hubs are blockchains specifically designed to connect Zones together. When a Zone creates an IBC connection with a Hub, it can automatically access (i.e. send to and receive from) every other Zone that is connected to it. As a result, each Zone only needs to establish a limited number of connections with a restricted set of Hubs. Hubs also prevent double spending among Zones. This means that when a Zone receives a token from a Hub, it only needs to trust the origin Zone of this token and each of the Hubs in its path. Hubs do not verify or execute transactions committed on other zones, so it is the responsibility of users to send tokens to zones that they trust.
There will be many Hubs within Cosmos network the first Hub to launch was the Cosmos Hub whose native staking token is called ATOM. ATOM tokens are specific to just the Cosmos Hub which is one hub of many, each with their own token. Transaction fees for the Cosmos Hub will be payable in multiple tokens so not just ATOMs whereas other Hubs such as IRIS has made it so that all transaction fees are paid in IRIS for transactions on its hub.
As mentioned, the Cosmos Hub is one of many hubs in the network and currently has a staking ratio of around 70% with its token ATOM having a market cap of just over $800 million. IRISnet was the second Hub to launch which currently has around 28% bonded with its token IRIS which has a market cap of just under $17 million. The Third Hub about to be launched later this month has its token SENT which has a market cap of around $3.4 million. As you can see the security of these 3 hubs differ wildly and as more and more hubs and then zones are brought online there is going to need to be a lot of tokens / incentivisation for validators.

Ethermint

Standard Cosmos zones / hubs don’t have smart contract functionality and so to enable this, as the Application layer is abstracted from the consensus layer via ABCI API described earlier, it allows Cosmos to port the code over from other blockchains such as Ethereum and use it with the Tendermint Consensus to provide access to the Ethereum Virtual Machine. This is what is called Ethermint.
This allows developers to connect their zones to specialised zones such as Ethermint to build and run smart contracts based on Solidity, whilst benefiting from the faster performance of the tendermint Conensus over the existing POW implementation currently. Whereas a normal Go Ethereum process runs at ~12.5 transactions per second (TPS), Ethermint caps out at 200 TPS. This is a comparison against existing Ethereum speeds, whilst obviously Ethereum are working on their own scaling solutions with Ethereum 2.0 which will likely be ready around the same time. Existing tools / dapps used on ethereum should easily be able to be ported over to Ethermint by the developer if required.
In addition to vertical scaling (with the increase in tps by using Tendermint consensus), it can also have multiple parallel chains running the same application and operated by a common validator set. So if 1 Ethermint zone caps out at 200 TPS then 4 Ethermint zones running in parallel would theoretically cap out at 800 TPS for example.

https://preview.redd.it/oboyonufiba31.png?width=554&format=png&auto=webp&s=18560aa44596fc2357590b54ddb39fd8ee1c8783
There is a huge number of developers / apps currently built on Ethereum, should a developer choose to migrate their DAPP over to Ethermint they would lose native compatibility with those on Ethereum (except through Peg Zone), but would gain compatibility with those running on Ethermint and others in the cosmos ecosystem.
You can find out more about Ethermint here and here
IBC
IBC stands for inter-blockchain communication protocol and is an end-to-end, connection-oriented, stateful protocol for reliable, ordered, authenticated communication between modules on separate distributed ledgers. Ledgers hosting IBC must provide a certain set of functions for consensus transcript verification and cryptographic commitment proof generation, and IBC packet relayers (off-chain processes) are expected to have access to network protocols and physical datalinks as required to read the state of one ledger and submit data to another.
In the IBC architecture, modules are not directly sending messages to each other over networking infrastructure, but rather creating messages to be sent which are then physically relayed via “Relayers”. “Relayers” run off-chain and continuously scan the state of each ledger via a light client connected to each of the 2 chains and can also execute transactions on another ledger when outgoing datagrams have been committed. For correct operation and progress in a connection between two ledgers, IBC requires only that at least one correct and live relayer process exists which can relay between the ledgers. Relays will need to be incentivised to perform this task (the method to which hasn’t been established as of this writing)
The relay process must have access to accounts on both chains with sufficient balance to pay for transaction fees. Relayers may employ application-level methods to recoup these fees, such by including a small payment to themselves in the packet data. More information on Relayers can be found here

https://preview.redd.it/twjzlc8hiba31.png?width=1100&format=png&auto=webp&s=2e546142573b61af031e27dac83ddca675a4b693
A high-level overview of the process is that Zone 1 commits an outbound message on its blockchan about sending say 1 x Token A to Hub1 and puts 1 x Token A in escrow. Consensus is reached in Zone 1, and then it’s passed to the IBC module to create a packet which contains the reference to the committed block, source and destination channel/ connection and timeout details and is added to Zone 1’s outbound queue as proof.
All relayers (who run off-chain) are continuously monitoring the state of Zone 1 via the Zone 1 light client. A Relayer such as Relayer 1 is chosen and submits a proof to Hub1 that Zone 1.
Hub 1 then sends a receipt as proof that it has received the message from Zone 1, relayer1 sends it to Zone 1. Zone 1 then removes it from its outbound queue and sends proof via another receipt to Hub1. Hub1 verifies the proof and mints the token.

https://preview.redd.it/d4dclm3iiba31.png?width=770&format=png&auto=webp&s=9ca521efc8580800067e1c4e3f74c0ab8df30555
This video below explains the process in more detail as well as covers some of the other points i raise later in this article so worth a watch (time stamped from 22:24 to 32:25) and also here from 38:53 to 42:50
https://youtu.be/5h8DXul4lH0?t=1344

Whilst there is an option for UDP style transfer where a zone will send a message to a Hub and it doesn’t care whether it gets there or in any order etc, Token transfers are going to require the TCP style connections in IBC where there is a send, receipt and then another receipt as explained above. Each Send, receipt followed by another receipt is going to take at least 2 blocks and so using Cosmos Hub block times as an example with 6.88 second block times a transfer between one zone and hub could take a minimum of 41.28 seconds. You also then have to factor in the amount of other transactions going through those at that time and relevant gas price to see whether it is able to use 2 consecutive blocks or whether it may take more. This is also explained in this video “ILP Summit 2019 | Cosmos and Interledger | Sunny Aggarwal” (time stamped) from to 12:50 to 15:45

In Part Two we will look at potential issues with multi hop routing, token transfers across multiple routes and Peg Zones, whilst also looking at other interoperability solutions that would resolve some of these issues and compliment the cosmos ecosystem. Part Two can be found here
submitted by xSeq22x to CryptoCurrency [link] [comments]

General info and list of exchanges for yezcoin

Real World Problems Related to Blockchain There have been several studies that look at the problems that may cause the delay in the adoption of the blockchain technology in the real-world applications, particularly the cryptocurrencies. 1. A large portion of the public have a negative impression towards cryptocurrencies, and blockchain, because of the past illegal activities associated with them. 2. Some cryptocurrency companies and exchanges are not fully compliant with government regulations due to the lack of will to change the status quo. 3. The existing architectures are not optimally scalable, and therefore may fail to serve up to larger groups of users. 4. The implementations of blockchain technology at many existing exchanges suffer from the trades-off between speed and security. 5. Complicated and error-prone processes can result in the loss of funds and lead to unhappy customers. 6. Digital wallet technology puts the burden on users to memorize and safeguard their wallet keys. 7. Small and medium size cryptocurrency exchanges face a liquidity dilemma. Customers expect liquidity but the exchanges won’t have enough liquidity unless they have more customers. Yezcoin Platform Solutions With our full awareness of the problems, we commit to providing the solutions to them. Yezcoin Platform is our brainchild that we proudly introduce to the blockchain community. 1. Yezcoin Platform assures that proper “know-your-customer (KYC)” and “anti-money laundering (AML)” are implemented with the blockchain technology 100% compliant with all government regulations. 2. Yezcoin Platform’s exchange model is a hybrid of a speedy centralized and a securely decentralized models. Yezcoin Platform can achieve the balance between the strengths of both models.
20180720_1331.001
3 3. Our expertise in advanced mobile technology allows an efficient mobile blockchain implementation that will allow users to participate in Yezcoin Platform using mobile phones. 4. With a 2-factor authentication process plus biometrics authentication, in addition to screening for fraud and blacklisted sites, Yezcoin Platform can provide customers with peace-of-mind security. 5. We mitigate the risk of private key management with multi-signature signing technology. Yezcoin Platform customers can manage their private keys via their biometric data. 6. Our 24/7 customer services will ensure that our help is always a click away. 7. Yezcoin Platform is forming a Cryptocurrency Exchange Alliance where cryptocurrency exchanges will benefit from high liquidity and a larger pool of customers. The Yezcoin Platform To achieve all the solutions we promise, Yezcoin Platform, by Yezcoin, is developed using several state-of-the-art technologies exist today for the future. Yezcoin = Hybrid Exchange + KYC & AML + Biometrics ID + Smart AI + Mobile Blockchain Yezcoin Hybrid Exchange A centralized exchange is generally fast but less secured, while a decentralized exchange is secure with lower speed. There is room in the middle to balance speed and security by storing sensitive information on the chain while performing order matching off of the chain. This way Yezcoin will have the speed of centralized model and the world class security of a decentralized model. KYC & AML Know Your Customer (KYC) and Anti Money Laundering (AML) rules have been the focus of government regulators trying to combat illegal activities in the cryptocurrency ecosystem. Unfortunately, existing cryptocurrency companies inherited KYC & AML issues since the birth of Bitcoin. As of now, no blockchain companies are able to claim that they are fully compliant with KYC & AML. Yezcoin will be the first company that is 100% KYC & AML compliant. Biometrics ID Biometric information usage has been increasing. Most modern smartphones come with Biometrics login capabilities. Enabling Biometrics ID to unlock a digital wallet is the next logical step. Many users have lost access to their wallets due to the loss of private keys. Yezcoin is using its proprietary encrypted Biometrics ID management solution to allow customers to unlock their digital wallets and securely manage their Biometrics ID. Smart AI Each cryptocurrency exchange trade comes with at least two options when making a purchase: 1) purchase with other cryptocurrency and pay full price; 2) purchase with the exchange currency and get a discounted price. Not all cryptocurrencies can be traded from every
20180720_1331.001
4 exchange and some cryptocurrencies are only available on certain exchanges. There are many options and complicated steps involved in a cryptocurrency trading transaction. Among many options, there is an optimal path where the customer will pay the lowest fee for the same transaction. Yezcoin’s Smart AI will perform all complicated calculations and selections and only present the customer with the best deal for both buying and selling. Mobile Blockchain Mobile devices have become a part of modern life and are increasing in power day by day. Unfortunately, the requirements to run blockchain nodes are too demanding. Yezcoin is working with blockchain experts and mobile engineers to enable our blockchain solution to run on mobile devices. It is a challenging but vital next step that must be achieved if we want the world to adopt blockchain technology. It must work on mobile devices and Yezcoin is committed to making it happen. Yezcoin Scam Detector and International Sanctions Check The cryptocurrency market has grown tremendously since 2017. A vast amount of funding has been invested into cryptocurrency. Sadly, the high growth in the market has attracted fraud as well. Criminals will impersonate someone who is a cryptocurrency market influencer and pretend that they are running a campaign to give back to investors only after investors send them the requested cryptocurrency. Thousands of investors have become victims of these scams. Furthermore, with the ease of transferring money, funding of these illegal activities has been on the rise and the use of an International Sanctions List has become less effective. To address these issues, Yezcoin has developed features to verify every account whether it matches any published International sanctions information at the registration and also to alert users if the sending wallet address matches one of 3,000+ known scammer addresses. NEO and the Solution for Scalability Yezcoin is using NEO Blockchain to support our proprietary identity management solution because we believe that NEO is our best solution. There are a number of blockchain platforms offering different approaches. Among those, NEO stands out with high throughputs, a supportive community and scalable solutions. NEO provides a node program, Blockchain Explorer, SDK Development Kit, Smart Contract Compiler and IDE Plugin, decentralized applications. One of the highlights of NEO’s solution is the DBFT consensus algorithm. Consensus NEO’s consensus algorithm, Delegated Byzantine Fault Tolerance (DBFT), is an improved version of classic Byzantine Fault Tolerance for scalability.
EXCHANGE LIST
Binance
Huobi
Kucoin
Bibox
Qryptos
Satoexchange
BIGone
Bitrue
Bilaxy
Bit-Z
Linkcoin
SECURE WALLET
Ledgerwallet
Trezor
submitted by icoinformation to yezcoin [link] [comments]

Bitcoin Q&A: Honest nodes and consensus Beyond Price - Bitcoins Impact On The Future - Byzantine Generals' - Andreas M. Antonopolous - Byzantine General's Problem Make Money Off Of The Bitcoin 'Carry Trade'  Binance Smartphone Coming  RBC Crypto Exchange Coming Technische Analyse: Bitcoin, Litecoin & Monero  Prijsanalyse #4  Misss Bitcoin I’ve Changed My Mind on Binance!! BNB #1 Altcoin!? Binance bevriest bitcoins, CBDC China af, Technische Analyse  #27 Madelon Praat  Misss Bitcoin [CS198.2x Week 1] Byzantine Fault Tolerance Tutorial 2 : Byzantines's General Problem El Problema del General Bizantino y blockchain

Byzantine Generals’ Problem The Byzantine Generals’ Problem (BFT) was discussed in 1982 by Shostak, Pease, and Lamport generalizes the Two Generals Problem published in 1975. In a nutshell, the Two Generals’ problem involves two generals preparing to attack an enemy but less likely to win due to lacking in the number of armies compared to the enemy. In 2008, Satoshi Nakamoto essentially solved the infamous computational issue called the “Byzantine generals’ problem” or the “Byzantine Fault.” Throughout the history of man, people used ledgers to record economic transactions and property ownership. A ledger is often referred to as the “principal book,” and entries can be recorded in stone, parchment, wood, metal, and […] Did the Byzantine Generals Problem really exist in the historical record, or is it just a thought experiment for fault tolerance? Is the Bitcoin network a middleman in the BGP? Is mining like a brute force attack? These questions are from the second and third sessions of MOOC 12, which took place on September 19th […] A Borussia Dortmund participant. Supply: a screenshot, Instagram/bvb09 Get your every day, bite-sized digest of cryptoasset and blockchain-related information – investigating the tales flying below the radar of at this time’s crypto information. Exchanges information Coinbase said it’s hiring extra workers in Japan, in one other trace that it may very well be set to […] The crypto native to one of the world’s most popular crypto-exchanges, Binance Coin is one of the few cryptos to recover all the losses incurred following Bitcoin’s price fall over 2-3 September. In fact, over the past week, BNB was observed to have risen by almost 26% on the charts. At the time of writing, however, BNB’s charts revealed that the final daily candle was a sharp red one, a ... Satoshi came up with a solution to the Byzantine Generals’ problem. It was the beginning of a revolution that will change the world in the next twelve years. Only a few people believed at first, the next few years were tumultuous but slowly it gained value and converted the hearts of few people at a time. Governments fought against it, banks said it was a scam, they said it facilitated ...

[index] [1501] [9624] [4643] [12747] [5117] [2731] [6794] [23736] [23257] [20207]

Bitcoin Q&A: Honest nodes and consensus

In this tutorial we will learn about the Byzantines's General Problem. Bitcoin and Byzantine Generals ... Live Session 2 with Andreas Antonopoulos, The Byzantine General's Problem - Duration: 50:46. MSc in Digital Currency - University of Nicosia 7,025 views. 50:46 ... BITCOIN: Was The .618 Fib Retrace A FAKE OUT? ️LIVE Crypto Analysis TA/BTC Cryptocurrency Price News - Duration: 23:18. Crypto Kirby Trading Recommended for you 23:18 These questions are from the MOOC sessions 7.2, 8.2, and 9.2 covering the Byzantine Generals' Problem, which took place on February 26th 2017, September 15th 2017, and February 23rd 2018 ... In this talk, Andreas reviews the early history of Bitcoin, the distributed computing problems it aimed to solve, the governance implications for centralised... 09:25 Binance & the Tether Cartel 11:54 Binance is Not Reducing Tether USDT Holdings 13:02 You Can't BS A BS'r: Binance Will Fail 13:48 Stop Using Binance! 14:12 Outro 📺Watch These Videos Again📺 Hi lieve mensen, De video eindigt te vroeg. Door problemen met mijn laptop heb ik niet de complete video kunnen uploaden. Morgen komt deel twee Sorry!! Liefs • BELANGRIJKE LINKS • Support mij ... The Byzantine Generals Problem and Blockchain Consensus Models ... Mike Maloney S1 • E8 From Bitcoin To Hedera Hashgraph (Documentary) Hidden Secrets Of Money Episode 8 - Duration: 1:14:26 ... Make Money Off Of The Bitcoin 'Carry Trade' Binance Smartphone Coming RBC Crypto Exchange Coming In today's crypto news, crypto analyst Plan B reveals his Bitcoin Carry trade that will net you ... The Byzantine Generals Problem and Blockchain Consensus Models ... BITCOIN Basico: Problema de los Generales Bizantinos Explicación sencilla - Duration: 4:54. Crypto Sheinix 236 views. 4:54. EL ...

#