Radix (XRD)

[2GOOD]

При тези пичове има всичко.

Най-вече свобода

Добре дошли

[danisapfirov]

Бих искал да благодаря, на 2Good, че макар и фен на биткойн блокверигата, вижда реалистично проблемите и не допуска арогантното отношение към инакомислещите станало характерна черта за биткойн максималистите.

Благодаря 2Good.

И така да си продължа с малко по-вътрешна информация как вървят нещата с платформата Radix...

Fuserleer:

just to let you guys know I'm back from my mini-trip to Florida
gotta dive right into patents today, so I'll catch up with the chat later today.
Plan this week time permitting is patents (ofc) and I'd like to have an alpha version of the chat for testing over the weekend
got some core stuff I want to do also so that we can start to prep for a high scale push.

За незапознатите Fuserleer е от района на Манчестър, мисля Донкастър, но в момента внедрява пилотен проект за застрахователна компания, от Силиконовата долина в Сан Франциско. Най-вероятно платформана няма да стартира с ICO, заради еластичния финансов модел. Но все пак не е окончателно. Очакват се новини за патентите както пише по-горе и ако те се впишат, вече ще може да се разкрива информация за технологиите.
Към края на седмицата вероятно ще има тест на системата.

[danisapfirov]

Актуални новини

Патента за Fabric ще бъде внесен до края на седмицата (14 Юли 2017) както е планирано.
Работата по него е започнала Януари 2017. Заявката за патентоване на технологията е
67 страници, 29000 думи, 20 графики.

За края на тази седмица също е обещан Алфа тест на чата.

Възможно е да има ново вътрешно ICO за бета тестери, понеже доста хора искат да инвестират още, а публично не се очертава.

[danisapfirov]

Най-после първия патент е внесен!!!

Fuserleer:

Today is a good day!

After literally months of hard work, 70 pages, 30,000 words and many iterations....the Radix NULL FABRIC patent is filed.

This now means that over the coming weeks I can talk publicly about our tech, release whitepapers and other information.

NULL FABRIC is the first of a series of patents we are filing, but is by far the most important, critical and largest of the set. The remaining will be filed over the remainder of 2017 (for now I need a wee break from patents!).

For today though, lets enjoy the moment and look to what the future may hold

fuserleer:
‎10‎:‎02‎ ‎PM
ITS FILED!
Likes 22

PS: За сега патентите покриват GB/EU. Разширяването на територията им към US и China може да стане по-късно.
Приходите ще идват главно от корпорации ползващи технологията за частни цели, публичните услуги - безплатни.
Дай боже да стане!

[eddy]

За да бъдеш бета тестер трябва ли да имаш някакви познания по програмиране? Тъй като искам да участвам в това ICO, но нямам такива!

[danisapfirov]

Не е необходимо непременно да разбираш от програмиране.

За включване може да пишете на Дан Хюз.
Първо тук https://forum.radix.global/threads/requ ... post-25342

И после напиши "магическите думи", че искаш да се присъединиш към чата https://forum.radix.global/threads/migr ... post-25324

Пиши дали си успял. Бих се радвал да има и друг човек от България.

[danisapfirov]

Дан Хюз обяснява какво е 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]

@Jazzer
Could you say a word or two about node selection for that verification path?
[BG] Би ли могъл да кажеш нещо за избора на възлите по пътеката за проверка?

@fuserleer
Verification path has 2 mechanisms which can be selected
1) path selection is meant to be random (or as much as possible)..this is fine for most events. Because the history of a nodes selection for a path is public, it is easily detected if a node is NOT selecting with sufficient randomness (always sends to nodes B or C but never D or E). Nodes that do this can then be penalized or not selected at all by other nodes and submitter for the verification process.
2) path is cyclic...as in submitter sends to node C, and a path length of n that ends at C should be found (C, D, X, Y, G, H, C). This is MUCH harder to find, and is suitable for high value or critical events.

These can be further refined such that a transaction with a high value could specify that the verification vertices contain only nodes with a mass greater than m, at the expense of a higher fee

The minimum nodes is the log(n)*3 where n is the size of the network
As the network grows and partitions, n becomes the number of nodes serving the partitions required by the Atom (edited)

[BG]
Пътеката за проверка има 2 механизма, които могат да бъдат избрани
1) изборът на пътека е предвиден по случаен начин (или до колкото това е възможно) .. този механизъм е добър за повечето събития. Тъй като историята на избор на възли е публична, лесно се открива, дали даден възел НЕ избира проверяващите възли достатъчно случайно (винаги изпраща към възли B или C, но никога D или E). Възлите, които правят това, могат да бъдат санкционирани или изобщо да престанат да бъдат избирани от други възли и податели за процеса на потвърждаване.
2) пътеката е циклична ... като изпращача изпраща до възел С, а дължината на пътеката е от n възли, и завършва в С, като трябва да бъдат открити (C, D, X, Y, G, H, C). Това е много по-трудно за намиране и метода е подходящ за събития с висока стойност или от критично значение.

Тези случаи могат да бъдат прецизирани така, че сделка с висока стойност да може да укаже, че проверяващите възли да бъдат само такива с маса по-голяма от m, за сметка на по-висока такса.

Минималния брой възли е log(n) * 3, където n е размерът на мрежата. Тъй като мрежата расте и се дели, n става броят на възлите, обслужващи дяловете, изисквани от Atom (редактирано)

@lanbadin
Isn't it possible for an attacker to forge a fake "proof" so that it invalidate x', then pass it to the other node?
[BG]
Възможно ли е атакуващ да създаде фалшиво "доказателство" така, че да направи невалидно събитието x', след което да го предаде на други възли?

@fuserleer
Sure...thats easy. Hard part is getting the network to accept it
as all nodes in the network know about x' and WHEN they saw it.
[BG]
Разбира се ... това е лесно. Трудната част е да се привлече мрежата да го приеме. Тъй като всички възли в мрежата знаят за x 'и КОГА са го видели.

@rotane
One attack vector I can think of is partition high-jacking. An attacker could try to create a partition and populate it with nodes he controls. Then wait for a victim to settle in his partition and bully him. How can you prevent that?
[BG]
Един вектор за атака за който мога да се сетя, е открадването на дял. Нападателят може да се опита да създаде дял и да го запълни с възли, които контролира. След това изчаква жертвата да се засели в дяла и да го превземе. Как може да се предотврати това?

@fuserleer
A transaction will span 2 or more partitions. One where it's coming from and the other where it's going to.
There are 18QUINTILLION partitions so the chance of two people sharing a partition is low.
Therefore if the attacker targets the partition of a particular user, because of this partition binding the rest of the network will hear about the transaction from the OTHER partition.
Your attack vector of someone spinning up a fake network entirely also potentially affects all crypto (I could spin up a fake bitcoin and sell them as bitcoins)
Growth of infrastructure is really the only protection here.
[BG]
Една транзакция ще обхваща 2 или повече дяла. Единия е откъдето идва, а другия е накъдето отива. Има 18 квинтилион дяла, така че шансът на двама души да споделят дял е малък. Следователно, ако нападателят е насочен към дял на конкретен потребител, поради това разпределение на дялове останалата част от мрежата ще чуе за транзакцията от ДРУГИЯ дял. Този вид атака, когато някой гради фалшива мрежа, потенциално засяга всички crypto (бих могъл да въртя фалшива bitcoin мрежа и да продавам жетони като bitcoins). Растежът на инфраструктурата е наистина единствената защита тук.


@rotane
I was thinking that partitioning would mean that it is llikely that more transactions happen within the partition than spanning to other partitions
what is the meaning of partitions then?
[BG]
Мислех си, че разделянето означава, че е вероятно повече транзакции да се изпълняват в рамките на дяла, отколкото да се простират до други дялове. Какъв е смисълът на дяловете тогава?

@fuserleer
Nodes operate partition groups, so say partitions 1B - 2B
The 18 Qt is the total partition space available.
[BG]
Възлите работят с групи от дялове, така например с дялове 1B - 2B.
18 квинтилиона е общото пространство на дяловете.

@rotane
From a processing perspective: is there any advantage or transaction processing between two nodes within the same partition compared to not being within the same partition?
[BG]
От гледна точка на обработката: има ли преимущество или обработка на транзакции между два възела в рамките на един и същ дял, в сравнение с това, че не са в рамките на един и същ дял?

@fuserleer
No it all costs the same
Generally though transactions that are in the same partition will be (at least for a couple decades) the same user and account
Until we reach such large scales, think of a partition more as a channel. As the chance of 2 users creating an account in the same partition before then is VERY low. Also remember all 18qt partitions exist from day one...they aren't created on demand as such.
[BG]
Не всичко това струва същото. Обикновено транзакции, които са в един и същ дял, ще бъдат (поне за няколко десетилетия) на един и същ потребител и профил. Докато стигнем до толкова големи мащаби, мислете за дяла като канал. Тъй като вероятността двама потребители да създават профил в същия дял преди това е много ниска. Също така помнете, че всички 18qt дялове съществуват от първия ден ... те не са създадени при поискване като такива.

@rotane
So partition selection is truely random?
[BG]
Така попадането в даден дял напълно случайно ли е?

@fuserleer
Yep...the account channel and the channel partition is derived from the accounts public key. Public keys are selected at random.
[BG]
Да ... каналът на профила и дялът на канала се извличат от публичния ключ на профила. Публичните ключове се избират на случаен принцип.

[danisapfirov]

danisapfirov
‎06‎:‎59‎ ‎AM
Morning, I already translated the initial description. Can I have a permission to post the content in my blog?

fuserleer
‎07‎:‎00‎ ‎AM
oooh nooooo!!!!!
not yet
I'm not going public with this just yet
"friends and family" only

danisapfirov
‎07‎:‎00‎ ‎AM
Ok

fuserleer
‎07‎:‎00‎ ‎AM
I need to create myself a block of time where I can just sit all day and answer the million questions I'll get with a public announcement
as soon as intend to public this, I'll let you know
then you can
(also need to finish the WP ofc too before then)

------------------------------------------------------------------------------------------------------------------
Както става ясно публикувал съм информацията малко предварително.
Ще изчакам Дан да каже кога може да се пише повече и съответно превежда по темата.
------------------------------------------------------------------------------------------------------------------

[eddy]

Чудя се дали няма да е по-коректно някой мод или админ да изтрие информацията? Засега?
Писах в темата за бета тестерите, но вече няколко дни няма промяна, до колкото виждам и останалите писали са със статус New Member, което ме навежда на мисълта, че админа е прекалено зает в момента и не може да обработи "заявките".. И поради тази причина нямам достъп до втория линк, който явно е само за бета тестери... Стоим и чакаме...