от danisapfirov » 23 Юли 2017, 21:22
Дан Хюз обяснява какво е NULL FABIC за първи път след като патента е внесен и
забраната за публикуване на информация за технологията отпада. Вижте как един програмист, разработчик
обяснява какво е изобретил. Текста по-долу ще бъде преведен и публикуван в блога криптосфера.
fuserleer 06:40 PM, San Francisco, California 23 07 2017
ok...here we go
anyone reading this, don't comment until I type /end
don't want comments in the middle of this brain dump
I'll keep it simple (ish) and will just skim across the main mechanisms and algorithms for how FABRIC operates with a couple of simple examples
[BG]
Добре ... от тук започваме
Който чете това да не коментира, докато не изпиша /край
Не искам коментари в средата на това разтоварване на ума.
Ще го напиша простичко и просто ще проследя основните механизми и алгоритми за това как работи FABRIC с няколко прости примера.
First some fundamentals.
FABRIC doesn't use blocks, miners or anything POx. The ledger has an architecture that supports natural partitioning (sharding), as in, it comes for free, and the consensus algorithm also supports it naturally. Each transaction achieves independent consensus, so that in the event of a conflict, and possible rollback of that transaction (rare and difficult as you'll see), only the children of that transaction are affected.
[BG]
Първо някои основни неща.
FABRIC не ползва блокове, миньори или каквото и да е POx. Записите от сделки имат архитектура, която поддържа естественото деление на много нишки (sharding), като в счетоводната книга това става безплатно, а консенсусният алгоритъм го поддържа естествено. Всяка сделка постига независим консенсус, така че в случай на конфликт и при възможно връщане на транзакция (рядко и трудно, както ще видите), само възлите имащи отношение към нея биват засегнати.
FABRIC takes inspiration from how the universe operates. There is no global state and it leverages heavily the principles behind general and special relativity.
In the Universe, even though there is no global state determining what state any and all matter is in, matter is able to interact with other matter simply by following a set of rules and reacts according to those rules.
Similarly, all matter in the universe has its own reference frame, which will have a different "time" to all other reference frames. That reference frame will experience a varying passage of time depending on how fast it is moving and how strong a gravitational field it is subject to.
Even though all reference frames have a different "time", total ordering in the Universe still prevails...for example, you, and I, know that this explanation of FABRIC is after yesterdays events and before tomorrows, even though we all have different "clocks"
[BG]
FABRIC се вдъхновява от начина, по който функционира Вселената. Няма глобален статус, а състоянието се определя от принципите на общата и специалната теория на относителността.
Макар във Вселената, да няма глобално състояние, определящо какво е състоянието на всяко материално тяло, материята е в състояние да взаимодейства с друга материя просто като следва набор от правила и реагира според тези правила.
По същия начин, цялата материя във Вселената има своя собствена референтна рамка, която има различно "време" от всички останали референтни рамки. Тази референтна рамка ще измине различно време в зависимост от това колко бързо се движи и колко силно е гравитационното поле, на което се подчинява.
Въпреки че всички референтни рамки имат различно "време", общата подредба и баланс надделяват при подреждането във Вселената ... например, вие и аз знаем, че това обяснение на FABRIC е след вчерашните събития и преди утре, въпреки, че всички ние имаме различни "часовници".
An event in FABRIC is represented by an Atom. An Atom maybe contain other Atoms to describe that event. The event is submitted to the network, and undergoes a verification process to determine the validity of the event.
This verification process works as follows (this is the broad strokes and is not exactly how it is implemented (which has a number of extra pieces for performance, efficiency, etc).
a' creates event x' and submits it to a node A. Node A checks the structure of the Atom and child Atoms (if any), signatures, dependencies and consumables. If the Atom is good, doesn't already exist, nor conflicts with anything, it creates a piece of information called a "verification vertex" represented by v'. Node A then selects another node it is connected to, node B, and passes x' along with v' to B.
B received the event x' along with v', and does the same as A. If there are no issues or conflicts, B also generates it's own v', selects a node it is connected to, node C, and passes x' along with all v' information is has (it's own v' and A's v').
This continues until a suitable number of hops have been performed for the size of the network (creators of events can also specify this).
[BG]
Събитие във FABRIC е представено от Atom. Атомът може да съдържа други атоми, за да опише това събитие. Събитието се изпраща в мрежата и преминава през процес на потвърждаване, за да се определи валидността на събитието.
Процесът на потвърждение работи по следния начин (това е общо казано и не е точно начина, по който се осъществява (има няколко допълнителни елемента при изпълнение, ефективност и т.н.).
А "създава събитие x" и го предава на възел А. Възел А проверява структурата на атомите на последващите атоми деца (ако има такива), подписи, зависимости и ресурси. Ако Атомът отговаря на критерии е добър, не съществува все още, нито влиза в противоречие, той създава информация, наречена "vertex за проверка", представена от v '. Тогава възел А избира друг възел, към който е свързан възел В, и предава събитието х 'заедно с вертекса за проверка v' с B.
B получава събитието x 'заедно с v' и прави същото като А. Ако няма проблеми или конфликти, B също генерира собствено v ', избира възел, към който е свързан възел C и предава x' заедно С цялата v 'информация която има (неговата собствена v' и тази която е на А).
Това продължава, докато не се извършат подходящ брой предавания за размера на мрежата (създателите на събития също могат да определят до кога).
If at any point during this process there is an issue (double spend for example), the node that discovered the conflict can signal to the nodes prior to it, and also the submitter, that they found an issue. They also have to provide proof (the other conflicting Atom).
[BG]
Ако в даден момент по време на този процес има проблем (например двоен разход), възелът, който е открил конфликта, може да сигнализира на възлите преди това, а също така и на възложителя, че са намерили проблем. Те също така трябва да предоставят доказателство (другият конфликтен Атом).
Assuming that our event x' is good, after this process is completed, it will have a set of verification vertices which act as its consensus information.
A verification vertex consists of n(HASH of x', previous observer ID, current observer ID, next observer ID, observer state, coordinate time, signature)
Combined, these vertices show us the route the event took through the network, and the state of all the nodes it touched (important!)
The event x' is then committed to all the nodes along the route, and then gossiped to the rest of the network.
Due to the gossiping, a small path is sufficient as we'll see later....generally a path length of log(n)*3 seems to be the sweet point in terms of consensus duration and performance/efficiency and has so far been able to resolve all conflicts that I have created in an attempt to break it.
[BG]
Ако приемем, че нашето събитие х 'е добро, след като този процес е завършен, той ще има набор от върхове на проверки, които действат като консенсусна информация. Vertex-а за потвърждение се състои от n (HASH на x ', предишния идентификатор на наблюдател, текущ идентификатор на наблюдател, следващ идентификатор на наблюдател, състояние на наблюдател, координатно време, подпис). В комбинация, тези върхове ни показват маршрута, който събитието е извършило през мрежата, и състоянието на всички възли, които е докоснало (важно!) Събитието x 'се ангажира с всички възли по маршрута и след това се разпространява към останалата част от мрежата .Благодарение на това разпространение наречено клюка, малък път е достатъчен, както ще видим по-късно .... Обикновено пътната дължина от Log (n) * 3 изглежда е сладката точка по отношение на продължителността при изграждане на консенсуса и изпълнението / ефективността и досега съм успял да разреша всички конфликти, които съм създал в опит да го прекъсна.
To resolve issues, the observer state is very important.
The observer state updates on EVERY event the node witnesses that is previously unseen. Whether that node is witnessing the event as part of the verification process, or via a gossip update.
Observer (or node) states are based on whats known a logical clock and works as follows (again, this is hugely simplified from the implementation, but will serve as a description just fine)
Say we have 3 nodes in the network, A, B and C and they have states of 10, 20, 30 respectively.
We have event x' which node A witnesses, so it increments its state to 11. B also witnesses it, so increments to 21. C (for some reason, bad connection?) does not, so stays on 30. (edited)
Now assume we have an event y' that is submitted to node C and conflicts with event x'
Node C hasn't seen event x' so y' checks out just fine, it increments its state to 31. It then forwards event y' to node B.
B HAS seen event x' with which y' conflicts. Assume B has also seen a few more since....lets say its state is currently 25.
B can recall event x' and see that his own state at the time of event x' was 21. This is clearly before y' which increment B's state to 26 if it were accepted. Therefore B knows that x' came before y' and rejects y' accordingly.
[BG]
За да се разрешат проблеми, състоянието на наблюдателя е много важно.
Статусът на наблюдателя актуализира ВСЯКО събитие на възлите, които преди това са били невидими. Дали възел е свидетел на събитие като част от процеса на потвърждаване или чрез обновяване на клюки.
Състоянието на наблюдателя (или възела) се основава на това, което е известно като логически часовник, и работи както следва (отново, това е много опростено от изпълнението, но ще служи като описание много добре).
Да кажем, че имаме 3 възли в мрежата, A, B и C и те имат състояния съответно от 10, 20 и 30.
Имаме събитие x 'койето е засвидетелствано от възел А, това увеличава състоянието му до 11. Ако В също свидетелства, часовника му нараства до 21. C (по някаква причина, лоша връзка?) не, актуализира часовника и така остава на 30.
Сега да предположим, че имаме събитие y ', което се предава на възел С и е в конфликти със събитие x'
Възел C не е видял събитие x така удостоверява 'y' и увеличава часовника на 31. Тогава се предава събитие y 'на възел B.
B е видял събитие x ' което e в конфликт с y. Да предположим, че B е видял и още няколко, .... да кажем, че състоянието му в момента е 25.
B може да си припомни събитие x 'и да види, че неговия собствен статус по време на събитие х' е 21. Ясно е, че това е преди y ', което увеличава състоянието на B на 26, ако е прието. Затова B знае, че x е станало преди това и отхвърля съответното конфликтно събитие.
The above is the simplest type of conflict in the network, but all conflict resolutions follow that principle.
If B was not sure (it got x' and y' from different places in the network simultaneously while synchronizing) it can park them until it has collected more information which will allow it to determine the same outcome from child transactions and the verification data they contain.
I will expand on these in more detail in the paper....this chat is not a great place to do that as they can get complex to explain before achieving clarity on how it resolves and diagrams will help a lot
A note on the gossip, due to the fact that all nodes update their state on ANY event they witness for the first time. Even nodes that are not part of any verification process can still determine immediately which of 2 events happened first providing that the events do not happen concurrently (there is a few seconds or more between the legit event and the conflict).
[BG]
Горното е най-простият тип конфликт в мрежата, но всички решения на конфликти следват този принцип. Ако B не е сигурен (получава x 'и y' от различни места в мрежата едновременно при синхронизиране), може да ги паркира, докато не събере повече информация, която ще му позволи да определи изхода от последващите транзакции и съдържанието на данните за потвърждаване.
Аз ще говоря по това подробно .... този чат не е най-доброто място да направя това, тъй като има сложни казуси за обяснение за постигане на яснота за това използването на диаграми ще помогне много.
Бележка за клюките, поради факта, че всички възли актуализират състоянието си за всяко събитие, което те свидетелстват за първи път. Дори възлите, които не са част от процеса на потвърждаване, могат да определят веднага кое от 2 събития е станало първо, ако събитията не се случват едновременно (има няколко секунди или повече между легитимното събитие и конфликта).
There is an edge case whereby a natural resolution of a conflict is NOT possible. This is called an "Isolated concurrent event" and is quite difficult to achieve, especially in a network with moderate number of nodes and traffic.
It requires that the attacker has a set of nodes that he uses to interact with the main network, produces an event, submits it, but also at the same time forges a conflicting event without leaking either it, or the state changes caused to his nodes for that conflicting event for a period of time.
To combat this, we borrow a little from EVEI.
Each event carries a mass, which is calculated from the time a resource that Atom is consuming has been static (such as some coins). This mass is transferred to the nodes that take part in the verification process and as a result nodes in the network then gain mass (or reputation).
In the case of an ICE, the mass of the nodes that took part in the verification of both events, AND those nodes that have taken part in dependents (past and also future for the main net event (merchant may have spent the funds too)) is summed and compared, with the winning event being the one with most mass backing it.
This borrows the principle from EVEI that an attackers nodes will need more mass than all other nodes in the network for his event to replace the "legit" event.
[BG]
Съществува случай, при който естественото разрешаване на конфликт не е възможно. Това се нарича "изолирано конкурентно събитие" и е доста трудно да се постигне, особено в мрежа с умерен брой възли и трафик.
То изисква атакуващия хакер да има набор от възли, които използва, за да взаимодейства с главната мрежа, да създаде събитие, да го представя, но в същото време да създаде конфликтно събитие, без да го пуска в цялата мрежа, или промените които та предизвиква в статута причинени на неговите възли да не излизат извън обхвата на неговите възли. Това конкурентно събитие трябва да бъде задържано между възлите на атакуващия за определен период от време.
За да се пребори мрежата с това, ние заемаме малко от EVEI.
Всяко събитие носи маса, която се изчислява от момента, в който ресурсът, който Атомът консумира, е статичен (като например някои монети). Тази маса се прехвърля на възлите, които участват в процеса на проверка и в резултат на това възлите в мрежата след това получават маса (или репутация).
В случай на ICE (изолирано конкурентно събитие), масата e на възлите, взели участие в проверката на двете събития, И тези възли, които са участвали в зависимости (минали, а също и в бъдеще за основното мрежово събитие (търговецът може би е използвал и средствата) ) се сумират и сравняват, като печелившото събитие е това, зад което стой най-голяма подкрепа свързана с маса.
Тук се заимства принцип от EVEI, че атакуващите възли ще се нуждаят от повече маса (репутация изградена при други сделки) от всички други възли в мрежата, за да подменят легитимното събитие.
Again, this is something I will get into more detail within the paper.
It should also be obvious that a nodes "mass" is directly correlated to the amount of work it has done, so can be used as such to distribute fees and new supply
that should do I think for an initial primer.... /end
[BG]
Отново, това е нещо, за което ще пиша по-подробно в статия.Също така трябва да е очевидно, че "масата" на възлите е пряко свързана с количеството работа, която е извършена, така че може да се използва за разпределяне на такси и нови емисии на жетони.
Това мисля ще свърши работа за начален пример .... / край
Последна промяна
danisapfirov на 25 Юли 2017, 20:12, променена общо 11 пъти