mirror of
https://github.com/alexgo-io/stacks-puppet-node.git
synced 2026-04-24 03:45:38 +08:00
change --- to --
This commit is contained in:
@@ -91,7 +91,7 @@ Atlas is ideal for tasks like:
|
||||
# Motivation
|
||||
|
||||
Atlas was designed to augment BNS. BNS allows each name to store a small
|
||||
amount of state---on the order of 20 bytes. The size is so small because the
|
||||
amount of state--on the order of 20 bytes. The size is so small because the
|
||||
state must be recorded to a public blockchain, where the cost per byte is
|
||||
high and the blockchain protocol limits the size of transactions.
|
||||
|
||||
@@ -112,7 +112,7 @@ While the Blockstack software stack expects that Atlas-hosted data is made up of
|
||||
DNS zone files, Atlas itself does not enforce this (nor does it care about the
|
||||
format of its chunks). It is designed as a general-purpose chunk store.
|
||||
Nevertheless, the ubiquitous use of Atlas to store data as DNS zone files has
|
||||
had an influence on its API design---fields and method names frequently allude
|
||||
had an influence on its API design--fields and method names frequently allude
|
||||
to zone files and zone file hashes. This is intentional.
|
||||
|
||||
The [public BNS API endpoint](https://core.blockstack.org) does not support
|
||||
@@ -282,7 +282,7 @@ such that the attacker takes control over all of the chunk's hash buckets.
|
||||
It can do so at any point in time after the chunk was first stored,
|
||||
because only the peers who maintain the chunk's hash bucket have to store it.
|
||||
This is a *fundamental* problem with structured overlay networks
|
||||
that perform request routing based on content hash---they give the attacker
|
||||
that perform request routing based on content hash--they give the attacker
|
||||
insight as to the path(s) the queries take through the peer graph, and thus
|
||||
reduce the number of paths the attacker must disrupt in order to censor the
|
||||
chunk.
|
||||
@@ -314,7 +314,7 @@ space).
|
||||
The preferential attachment property means that an adaptive adversary can game the node's
|
||||
neighbor selection algorithm by inserting malicious nodes that do not
|
||||
forward routing or lookup requests. The attacker does not even have to eclipse
|
||||
the victim node---the victim node will simply prefer to talk to the attacker's unhelpful nodes
|
||||
the victim node--the victim node will simply prefer to talk to the attacker's unhelpful nodes
|
||||
instead of helpful honest nodes. In doing so, the attacker can prevent honest peers from discovering each
|
||||
other and each other's chunks.
|
||||
|
||||
|
||||
@@ -189,7 +189,7 @@ At the time of this writing, by far the largest BNS namespace is the `.id`
|
||||
namespace. Names in the `.id` namespace are meant for resolving user
|
||||
identities. Short names in `.id` are more expensive than long names, and have
|
||||
to be renewed by their owners every two years. Name registration fees are not
|
||||
paid to anyone in particular---they are instead sent to a "black hole" where they are
|
||||
paid to anyone in particular--they are instead sent to a "black hole" where they are
|
||||
rendered unspendable (the intention is to discourage ID sqautters).
|
||||
|
||||
Unlike DNS, *anyone* can create a namespace and set its properties.
|
||||
@@ -503,7 +503,7 @@ thing, since it prevents spammers from both filling up the blockchain with
|
||||
garbage data and in turn prevents spammers from filling up BNS name databases with junk.
|
||||
|
||||
In addition to the transaction fee, BNS imposes a *registration fee*. Not all
|
||||
names are created equal---some names are more desirable than others. BNS
|
||||
names are created equal--some names are more desirable than others. BNS
|
||||
uses the registration fee to ensure that more desirable names cost more, so they
|
||||
are less likely to be squatted. In addition, the registration fee is an
|
||||
incentive mechanism for developers to create and curate namespaces
|
||||
@@ -811,7 +811,7 @@ the BNS peer needs to do so, and must know how to *reject* both invalid transact
|
||||
as well as well-formed transactions from dishonest peers (i.e. peers that do not
|
||||
follow the same consensus rules).
|
||||
|
||||
BNS nodes do not directly communicate with one another---by design, the set of
|
||||
BNS nodes do not directly communicate with one another--by design, the set of
|
||||
BNS peers is not enumerable. The only shared communication medium between BNS
|
||||
peers is the blockchain.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user