What is Cardano? An introduction to the cryptocurrency being built by scientists(bitcoinbeginner.com)
bitcoinbeginner.com
What is Cardano? An introduction to the cryptocurrency being built by scientists
https://www.bitcoinbeginner.com/blog/what-is-cardano/
21 comments
Can someone please explain to me why is this being voted up? This an obvious fluff which hand waves through most of the stuff by saying - refer to the cardano website. Then, if you are impressed by the lack of info, there are two referral links for coinbase and binance.
Brief review I did of the paper a while back:
Forkable strings (a la Ouroboros) makes unrealistic assumptions.
Ouroboros is a Proof-of-Stake altcoin that comes with a security proof based on the idea of "forkable strings".
As a brief introduction: each round/epoch consists of a sequence (of length n) of leaders, each chosen from a set of stakeholders, that have the authority to decide between multiple valid branches of a fork. They model this, using a concept they invent called a "forkable string", and prove various security properties about it.
The full definition can be read in page 16 of the Ouroboros paper. One key assumption is that they assume all the honest leaders (say, at indexes H = [i], a subsequence of the full sequence [0, 1, ..., n-1]), will only commit to chains that have increasing depth, as i increases.
For example, suppose that our sequence of leaders is 5 stakeholders long [s1 ... s5], and stakeholders s2, s3, s5 are honest. Suppose we start off at block O. Then suppose that s2 commits a new block B 2 blocks away from O:
O <-- ? <-- B[s2]
(The arrows go in the opposite direction in the paper, but I prefer it this way because that is how the references go. ? knows about O, O doesn't know about ?.)
Then a "forkable string" assumes that s3 knows about B[s2], and since s3 is honest (as we assumed for our scenario) she will commit her new block C, >2 blocks away from O. Suppose she commits it 3 blocks away:
O <-- ? <-- ? <-- C[s3]
Then s5 knows about C[s3], and being honest, will commit his new block E, >3 blocks away from O:
O <-- ? <-- ? <-- ? [..] <-- E[s5]
Using this property (and others) of forkable strings, the authors then go on to prove various security properties about Ouroboros.
As you might have noticed already, this property assumes that all honest nodes can reliably receive all other honest nodes' blocks. The paper in fact freely admits this in various places, e.g. on page 10 and page 16. I was already skeptical when reading that, but the fact that this assumption forms such a key requirement of their security proof raised my eyebrow(s) even further.
If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings. Everyone can just sync (union) their view of what blocks they've seen with each other via this magical "reliable channel", and run a deterministic pure algorithm like `sort | head -n1` to disambiguate any forks!
The whole point of a maxvalid() algorithm (e.g. PoW in bitcoin) is to secure the case where nodes including honest ones, don't have reliable channels to each other e.g. because they are under attack, or because of pervasive network latency. As soon as you assume they already have a reliable channel to everyone else, you have already "begged the question", and anything you build on top of this (like `sort | head -n1`) is guaranteed to "work".
(Another strange thing, is that the authors allow the attacker to selectively show different honest nodes different stuff [1], but for some reason is not able to prevent honest nodes from seeing all other honest nodes' stuff.)
[1] e.g. page 17 "the honest player associated with the third slot is shown a chain of length 1 produced by the adversarial player of slot 2" but is unable to see the other (2) node, that eventually forms the ^t chain ("tine").
Forkable strings (a la Ouroboros) makes unrealistic assumptions.
Ouroboros is a Proof-of-Stake altcoin that comes with a security proof based on the idea of "forkable strings".
As a brief introduction: each round/epoch consists of a sequence (of length n) of leaders, each chosen from a set of stakeholders, that have the authority to decide between multiple valid branches of a fork. They model this, using a concept they invent called a "forkable string", and prove various security properties about it.
The full definition can be read in page 16 of the Ouroboros paper. One key assumption is that they assume all the honest leaders (say, at indexes H = [i], a subsequence of the full sequence [0, 1, ..., n-1]), will only commit to chains that have increasing depth, as i increases.
For example, suppose that our sequence of leaders is 5 stakeholders long [s1 ... s5], and stakeholders s2, s3, s5 are honest. Suppose we start off at block O. Then suppose that s2 commits a new block B 2 blocks away from O:
O <-- ? <-- B[s2]
(The arrows go in the opposite direction in the paper, but I prefer it this way because that is how the references go. ? knows about O, O doesn't know about ?.)
Then a "forkable string" assumes that s3 knows about B[s2], and since s3 is honest (as we assumed for our scenario) she will commit her new block C, >2 blocks away from O. Suppose she commits it 3 blocks away:
O <-- ? <-- ? <-- C[s3]
Then s5 knows about C[s3], and being honest, will commit his new block E, >3 blocks away from O:
O <-- ? <-- ? <-- ? [..] <-- E[s5]
Using this property (and others) of forkable strings, the authors then go on to prove various security properties about Ouroboros.
As you might have noticed already, this property assumes that all honest nodes can reliably receive all other honest nodes' blocks. The paper in fact freely admits this in various places, e.g. on page 10 and page 16. I was already skeptical when reading that, but the fact that this assumption forms such a key requirement of their security proof raised my eyebrow(s) even further.
If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings. Everyone can just sync (union) their view of what blocks they've seen with each other via this magical "reliable channel", and run a deterministic pure algorithm like `sort | head -n1` to disambiguate any forks!
The whole point of a maxvalid() algorithm (e.g. PoW in bitcoin) is to secure the case where nodes including honest ones, don't have reliable channels to each other e.g. because they are under attack, or because of pervasive network latency. As soon as you assume they already have a reliable channel to everyone else, you have already "begged the question", and anything you build on top of this (like `sort | head -n1`) is guaranteed to "work".
(Another strange thing, is that the authors allow the attacker to selectively show different honest nodes different stuff [1], but for some reason is not able to prevent honest nodes from seeing all other honest nodes' stuff.)
[1] e.g. page 17 "the honest player associated with the third slot is shown a chain of length 1 produced by the adversarial player of slot 2" but is unable to see the other (2) node, that eventually forms the ^t chain ("tine").
> Then a "forkable string" assumes that s3 knows about B[s2], and since s3 is honest (as we assumed for our scenario) she will commit her new block C, >2 blocks away from O. Suppose she commits it 3 blocks away:
I think you're misunderstanding the protocol.
The purpose of the PVSS scheme outlined in section 5.2 is to provide all stakeholders with a verifiable random seed R, which they then independently use to identify all slot leaders for the epoch. This means that—irrespective of honesty—stakeholder si can only create a block in slot i. In particular, in your example stakeholders s2, s3, and s5 can only create blocks in slots 2, 3, and 5, respectively.
The strategy left to the dishonest stakeholder si is to create duplicate blocks in slot i and distribute them to different portions of the network. See figure 5 on p. 17 for an example.
> If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings.
The protocol definitely does not make this assumption. The purpose of the forkable strings analysis is to show that the probability that a random seed R generates an advantageous slot assignment for forking attacks decays exponentially with the number of slots in the epoch.
If honest nodes could all communicate reliably this analysis would be unnecessary. For example in the case given in figure 5, stakeholders s3 and s5 could both abandon their tines and fill in slots 3 and 5 on the middle tine.
I think you're misunderstanding the protocol.
The purpose of the PVSS scheme outlined in section 5.2 is to provide all stakeholders with a verifiable random seed R, which they then independently use to identify all slot leaders for the epoch. This means that—irrespective of honesty—stakeholder si can only create a block in slot i. In particular, in your example stakeholders s2, s3, and s5 can only create blocks in slots 2, 3, and 5, respectively.
The strategy left to the dishonest stakeholder si is to create duplicate blocks in slot i and distribute them to different portions of the network. See figure 5 on p. 17 for an example.
> If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings.
The protocol definitely does not make this assumption. The purpose of the forkable strings analysis is to show that the probability that a random seed R generates an advantageous slot assignment for forking attacks decays exponentially with the number of slots in the epoch.
If honest nodes could all communicate reliably this analysis would be unnecessary. For example in the case given in figure 5, stakeholders s3 and s5 could both abandon their tines and fill in slots 3 and 5 on the middle tine.
[deleted]
[deleted]
> [1] e.g. page 17 "the honest player associated with the third slot is shown a chain of length 1 produced by the adversarial player of slot 2" but is unable to see the other (2) node, that eventually forms the ^t chain ("tine").
This could be explained by the adversarial player creating two blocks very close to the end of the round during slot 2. If the third player creates his block near the beginning of his round, then he would be unaware of the other (2) node.
To your main point:
> As you might have noticed already, this property assumes that all honest nodes can reliably receive all other honest nodes' blocks. The paper in fact freely admits this in various places, e.g. on page 10 and page 16. I was already skeptical when reading that, but the fact that this assumption forms such a key requirement of their security proof raised my eyebrow(s) even further.
Even in bitcoin, all nodes must eventually be able to communicate with the p2p network (and therefore be able to receive all other nodes' blocks, honest or otherwise). How could you tell if there is a fork, otherwise?
The assumptions are explained in page 6, under Diffuse functionality:
Additionally, parties can instruct the functionality to diffuse a message, in which case the message will be appended to each party’s incoming string... The adversary, when activated, may also interact with the functionality and is allowed to read all inboxes and all diffuse requests and deliver messages to the inboxes in any order it prefers.
In other words, the adversary is allowed to send individual messages to individual parties, but not prevent a party from receiving any other party's message within a round (which corresponds to the time between blocks).
An adversary could send a message to a slot leader and perform a DOS attack to prevent him from receiving other messages from other parties, and this seems to be an overlooked attack vector. Although, on the other hand, I'm not sure how the adversary would know which ip address to perform the DOS attack on. Just knowing the stake address wouldn't reveal that information. So unless the adversary has the power to DDOS a large percentage of the network, they couldn't do this.
> If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings.
If there is no leadership selection, there is no way to throttle the speed that blocks are received, and the system could simply be DOS'ed by overloading it with blocks.
> Everyone can just sync (union) their view of what blocks they've seen with each other via this magical "reliable channel", and run a deterministic pure algorithm like `sort | head -n1` to disambiguate any forks!
The point is to prevent long running forks. "sort | head -n1" would work if the branches were all static, but not if an adversary with a large, but not majority stake, saved both branches and then added a block to them, the new longer branch would be preferred. If an adversary could do this, they could create a long standing fork, lasting indefinitely. pg 15 (in the below text, a w of 1 indicates an adversarial node, and a w of 0 indicates an honest node):
We start with some intuition on our approach to analyze the protocol. Let w ∈ {0, 1}n be a characteristic string for a sequence of slots S. Consider two observers that (i.) go offline immediately prior to the commencement of S, (ii.) have the same view C 0 of the current chain prior to the commencement of S, and (iii.) come back online at the last slot of S and request an update of their chain. A fundamental concern in our analysis is the possibility that such observers can be presented with a “diverging” view over the sequence S: specifically, the possibility that the adversary can force the two observers to adopt two different chains C 1 , C 2 whose common prefix is C 0 .
> The whole point of a maxvalid() algorithm (e.g. PoW in bitcoin) is to secure the case where nodes including honest ones, don't have reliable channels to each other e.g. because they are under attack, or because of pervasive network latency. As soon as you assume they already have a reliable channel to everyone else, you have already "begged the question", and anything you build on top of this (like `sort | head -n1`) is guaranteed to "work".
The point of the maxvalid() algorithm is to prevent the doublespend attack. Handling the case where all nodes don't have reliable channels to each other is overkill. You just need to handle cases where some nodes don't have reliable channels.
This could be explained by the adversarial player creating two blocks very close to the end of the round during slot 2. If the third player creates his block near the beginning of his round, then he would be unaware of the other (2) node.
To your main point:
> As you might have noticed already, this property assumes that all honest nodes can reliably receive all other honest nodes' blocks. The paper in fact freely admits this in various places, e.g. on page 10 and page 16. I was already skeptical when reading that, but the fact that this assumption forms such a key requirement of their security proof raised my eyebrow(s) even further.
Even in bitcoin, all nodes must eventually be able to communicate with the p2p network (and therefore be able to receive all other nodes' blocks, honest or otherwise). How could you tell if there is a fork, otherwise?
The assumptions are explained in page 6, under Diffuse functionality:
Additionally, parties can instruct the functionality to diffuse a message, in which case the message will be appended to each party’s incoming string... The adversary, when activated, may also interact with the functionality and is allowed to read all inboxes and all diffuse requests and deliver messages to the inboxes in any order it prefers.
In other words, the adversary is allowed to send individual messages to individual parties, but not prevent a party from receiving any other party's message within a round (which corresponds to the time between blocks).
An adversary could send a message to a slot leader and perform a DOS attack to prevent him from receiving other messages from other parties, and this seems to be an overlooked attack vector. Although, on the other hand, I'm not sure how the adversary would know which ip address to perform the DOS attack on. Just knowing the stake address wouldn't reveal that information. So unless the adversary has the power to DDOS a large percentage of the network, they couldn't do this.
> If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings.
If there is no leadership selection, there is no way to throttle the speed that blocks are received, and the system could simply be DOS'ed by overloading it with blocks.
> Everyone can just sync (union) their view of what blocks they've seen with each other via this magical "reliable channel", and run a deterministic pure algorithm like `sort | head -n1` to disambiguate any forks!
The point is to prevent long running forks. "sort | head -n1" would work if the branches were all static, but not if an adversary with a large, but not majority stake, saved both branches and then added a block to them, the new longer branch would be preferred. If an adversary could do this, they could create a long standing fork, lasting indefinitely. pg 15 (in the below text, a w of 1 indicates an adversarial node, and a w of 0 indicates an honest node):
We start with some intuition on our approach to analyze the protocol. Let w ∈ {0, 1}n be a characteristic string for a sequence of slots S. Consider two observers that (i.) go offline immediately prior to the commencement of S, (ii.) have the same view C 0 of the current chain prior to the commencement of S, and (iii.) come back online at the last slot of S and request an update of their chain. A fundamental concern in our analysis is the possibility that such observers can be presented with a “diverging” view over the sequence S: specifically, the possibility that the adversary can force the two observers to adopt two different chains C 1 , C 2 whose common prefix is C 0 .
> The whole point of a maxvalid() algorithm (e.g. PoW in bitcoin) is to secure the case where nodes including honest ones, don't have reliable channels to each other e.g. because they are under attack, or because of pervasive network latency. As soon as you assume they already have a reliable channel to everyone else, you have already "begged the question", and anything you build on top of this (like `sort | head -n1`) is guaranteed to "work".
The point of the maxvalid() algorithm is to prevent the doublespend attack. Handling the case where all nodes don't have reliable channels to each other is overkill. You just need to handle cases where some nodes don't have reliable channels.
(Trying to group related points together)
> Even in bitcoin, all nodes must eventually be able to communicate with the p2p network (and therefore be able to receive all other nodes' blocks, honest or otherwise). How could you tell if there is a fork, otherwise?
The security-correctness proof of bitcoin doesn't depend on "honest nodes reliably receiving all honest nodes' blocks". Actually bitcoin is simple in that it doesn't try to distinguish between honest vs malicious, the security argument just says with overwhelming probabliity that any colluding subset of nodes with >50% computation wins.
----
> In other words, the adversary is allowed to send individual messages to individual parties, but not prevent a party from receiving any other party's message within a round (which corresponds to the time between blocks).
But transports are unreliable and systems buggy, and so this could happen anyways in a real run of the protocol.
> An adversary could send a message to a slot leader and perform a DOS attack to prevent him from receiving other messages from other parties, and this seems to be an overlooked attack vector. Although, on the other hand, I'm not sure how the adversary would know which ip address to perform the DOS attack on. [..]
Honest parties of the protocol have to be able to contact the leader by the normal operation of the protocol, so the attacker could just hook into this mechanism.
More generally, these are not holes that one wants to leave untreated by the protocol, it can open up escalation / chained attacks.
----
> The point is to prevent long running forks. "sort | head -n1" would work if the branches were all static, but not if an adversary with a large, but not majority stake, saved both branches and then added a block to them, the new longer branch would be preferred. [..]
When I say `sort | head -n1` I don't mean "also prefer longer branches", I mean only `sort | head -n1`, unconditionally on all fork-points. Assuming honest nodes can all reliably broadcast (which the paper does, even explicitly on page 16), this is enough to achieve the "unforkability" property. (The attack you mentioned wouldn't work because the longer branch would still be ignored.)
> Handling the case where all nodes don't have reliable channels to each other is overkill. You just need to handle cases where some nodes don't have reliable channels.
I agree the former is overkill, but the security assumptions of "forkable strings" don't handle the latter case, it assumes it's already handled.
> Even in bitcoin, all nodes must eventually be able to communicate with the p2p network (and therefore be able to receive all other nodes' blocks, honest or otherwise). How could you tell if there is a fork, otherwise?
The security-correctness proof of bitcoin doesn't depend on "honest nodes reliably receiving all honest nodes' blocks". Actually bitcoin is simple in that it doesn't try to distinguish between honest vs malicious, the security argument just says with overwhelming probabliity that any colluding subset of nodes with >50% computation wins.
----
> In other words, the adversary is allowed to send individual messages to individual parties, but not prevent a party from receiving any other party's message within a round (which corresponds to the time between blocks).
But transports are unreliable and systems buggy, and so this could happen anyways in a real run of the protocol.
> An adversary could send a message to a slot leader and perform a DOS attack to prevent him from receiving other messages from other parties, and this seems to be an overlooked attack vector. Although, on the other hand, I'm not sure how the adversary would know which ip address to perform the DOS attack on. [..]
Honest parties of the protocol have to be able to contact the leader by the normal operation of the protocol, so the attacker could just hook into this mechanism.
More generally, these are not holes that one wants to leave untreated by the protocol, it can open up escalation / chained attacks.
----
> The point is to prevent long running forks. "sort | head -n1" would work if the branches were all static, but not if an adversary with a large, but not majority stake, saved both branches and then added a block to them, the new longer branch would be preferred. [..]
When I say `sort | head -n1` I don't mean "also prefer longer branches", I mean only `sort | head -n1`, unconditionally on all fork-points. Assuming honest nodes can all reliably broadcast (which the paper does, even explicitly on page 16), this is enough to achieve the "unforkability" property. (The attack you mentioned wouldn't work because the longer branch would still be ignored.)
> Handling the case where all nodes don't have reliable channels to each other is overkill. You just need to handle cases where some nodes don't have reliable channels.
I agree the former is overkill, but the security assumptions of "forkable strings" don't handle the latter case, it assumes it's already handled.
> The security-correctness proof of bitcoin doesn't depend on "honest nodes reliably receiving all honest nodes' blocks". Actually bitcoin is simple in that it doesn't try to distinguish between honest vs malicious, the security argument just says with overwhelming probabliity that any colluding subset of nodes with >50% computation wins.
But only if those "colluding subset of nodes" can eventually be able to communicate with each other (and the users they are trying to collude against). Maybe you're reading too much into what I'm saying, but it's basically a variant of "If a tree falls and no one is around to hear it, does it make a sound?" That is, if the nodes can't communicate with each other, then obviously, it doesn't matter what they publish if the other nodes can't hear it.
----
> But transports are unreliable and systems buggy, and so this could happen anyways in a real run of the protocol.
It's true that it could happen, and the paper doesn't seem to account for this. But the general idea is that for an attacker to pull off a double spend, they'd have to reliably be able to create a fork for a long string of nodes. If the network has a single hiccup, it may give the attacker the ability to create a short fork, but it would quickly be resolved once the network became reliable again.
> Honest parties of the protocol have to be able to contact the leader by the normal operation of the protocol, so the attacker could just hook into this mechanism.
Yes, but they don't need to know that the slot leader is the slot leader to do so. He could be hidden within thousands of running nodes. How would the attacker know which one to DOS?
> More generally, these are not holes that one wants to leave untreated by the protocol, it can open up escalation / chained attacks.
Yes, I agree with you there. If an attacker found the ip address which corresponds to a large stake, by some means, then he could perform a DOS attack.
----
> When I say `sort | head -n1` I don't mean "also prefer longer branches", I mean only `sort | head -n1`, unconditionally on all fork-points. Assuming honest nodes can all reliably broadcast (which the paper does, even explicitly on page 16), this is enough to achieve the "unforkability" property. (The attack you mentioned wouldn't work because the longer branch would still be ignored.)
If I'm understanding you correctly, than this would make it even worse! Suppose at block n+100, an attacker made a fork at block n. If the attacker's branch of length n was determined to be "better" by the sort algorithm than the branch of length n+100, then the system would reorg in favor of the attacker, and 100 blocks would be lost.
> I agree the former is overkill, but the security assumptions of "forkable strings" don't handle the latter case, it assumes it's already handled.
I don't understand why your "sort | head -n1" algorithm would work, so I can't follow this to your conclusion.
Are you assuming that no node could go offline at any time?
---
You have a point about buggy networks, and there is an attack vector of an adversary performing a DOS against an honest node, as we talked about beforehand.
However, I doubt these considerations would have much of an impact. First, in order to double spend, you'd need to reliably be able to maintain a fork.
Second, you haven't mentioned is covert vs overt attacks. If an attacker was to sign two different blocks, the network would quickly be able to determine this as foul play. Since the attacker's stake is associated with the blocks, it would be trivial to punish an attacker severely, by destroying his funds. So, if we eliminate cases where the attacker signs more than one block, then his chances diminish substantially.
So, I do see the proof doesn't consider some circumstances, but I think they are rare enough that it wouldn't be an issue in the real world.
But only if those "colluding subset of nodes" can eventually be able to communicate with each other (and the users they are trying to collude against). Maybe you're reading too much into what I'm saying, but it's basically a variant of "If a tree falls and no one is around to hear it, does it make a sound?" That is, if the nodes can't communicate with each other, then obviously, it doesn't matter what they publish if the other nodes can't hear it.
----
> But transports are unreliable and systems buggy, and so this could happen anyways in a real run of the protocol.
It's true that it could happen, and the paper doesn't seem to account for this. But the general idea is that for an attacker to pull off a double spend, they'd have to reliably be able to create a fork for a long string of nodes. If the network has a single hiccup, it may give the attacker the ability to create a short fork, but it would quickly be resolved once the network became reliable again.
> Honest parties of the protocol have to be able to contact the leader by the normal operation of the protocol, so the attacker could just hook into this mechanism.
Yes, but they don't need to know that the slot leader is the slot leader to do so. He could be hidden within thousands of running nodes. How would the attacker know which one to DOS?
> More generally, these are not holes that one wants to leave untreated by the protocol, it can open up escalation / chained attacks.
Yes, I agree with you there. If an attacker found the ip address which corresponds to a large stake, by some means, then he could perform a DOS attack.
----
> When I say `sort | head -n1` I don't mean "also prefer longer branches", I mean only `sort | head -n1`, unconditionally on all fork-points. Assuming honest nodes can all reliably broadcast (which the paper does, even explicitly on page 16), this is enough to achieve the "unforkability" property. (The attack you mentioned wouldn't work because the longer branch would still be ignored.)
If I'm understanding you correctly, than this would make it even worse! Suppose at block n+100, an attacker made a fork at block n. If the attacker's branch of length n was determined to be "better" by the sort algorithm than the branch of length n+100, then the system would reorg in favor of the attacker, and 100 blocks would be lost.
> I agree the former is overkill, but the security assumptions of "forkable strings" don't handle the latter case, it assumes it's already handled.
I don't understand why your "sort | head -n1" algorithm would work, so I can't follow this to your conclusion.
Are you assuming that no node could go offline at any time?
---
You have a point about buggy networks, and there is an attack vector of an adversary performing a DOS against an honest node, as we talked about beforehand.
However, I doubt these considerations would have much of an impact. First, in order to double spend, you'd need to reliably be able to maintain a fork.
Second, you haven't mentioned is covert vs overt attacks. If an attacker was to sign two different blocks, the network would quickly be able to determine this as foul play. Since the attacker's stake is associated with the blocks, it would be trivial to punish an attacker severely, by destroying his funds. So, if we eliminate cases where the attacker signs more than one block, then his chances diminish substantially.
So, I do see the proof doesn't consider some circumstances, but I think they are rare enough that it wouldn't be an issue in the real world.
[deleted]
More detailed information: https://cardanodocs.com/introduction/
While the concept of a peer-reviewed cryptocurrency is an interesting one, and certainly has merit, I can't seem to figure out what Cardano offers that existing, and well established, cryptocurrencies like Ethereum don't.
Ethereum is pretty flawed actually, it's easily congested when new ICO's launch for example, and some other network issues.
Though, I can't say how this new crypto will handle things, I AM interested in seeing how Nxt/Ardor saga play out. It's much more secure, and stable than btc/ethereum and I think the child chain setup is going to be very popular.
Though, I can't say how this new crypto will handle things, I AM interested in seeing how Nxt/Ardor saga play out. It's much more secure, and stable than btc/ethereum and I think the child chain setup is going to be very popular.
Nothing, as far as I can tell. The goal seems to be just to do it better.
There MAY be an idea of keeping the computing layer private, meaning you can run computations w/o everyone seeing how it works, which is the case with Ethereum block chains. That's just the impression I get from reading their docs.
There MAY be an idea of keeping the computing layer private, meaning you can run computations w/o everyone seeing how it works, which is the case with Ethereum block chains. That's just the impression I get from reading their docs.
They mostly pitch how their development process / governance is better. "Scientific" is the word they always use.
science-based dragon-based cryptocurrency built on peer review pixiedust of the academia elite
there may be some good ideas buried under all this bullshit marketing buzzwordery, we'll probably find out next year
there may be some good ideas buried under all this bullshit marketing buzzwordery, we'll probably find out next year
This is advertising.
I disagree. Within the last week Cardano has gone from relatively unknown to the 6th highest market cap on https://coinmarketcap.com. There is certainly enough of a surge in interest to make this a relevant post.
I'm pretty sure the fact that the "article" links to both Coinbase and Binance with referral IDs classifies this as advertising.
I wouldn't mind if the link was replaced with one that didn't include "buy now" links, but the topic of "What is Cardano?" is perfectly fine for this board.
Oh I didn't even notice those were links. That puts a very different spin on the article...
This is incorrect
XMR is the token name of Monero
ADA is the token name of Cardano