Radix (XRD)

[danisapfirov]

Какво е разделна обработка (sharding)?
-------------------------------------------------
"Sharding is a type of database partitioning that separates very large databases the into smaller, faster, more easily managed parts called data shards. The word shard means a small part of a whole."

Вид разделяне на база данни, при която се разделя много голяма база данни на малки парченца, за бързина, по-лесна обработка. Думата означава малка част от цялото.

При Radix Tempo, не става въпрос само за разделяне на базата данни на малки части. Това е лесно да се постигне и почти всички го правят. Достатъчно е да се погледнат данните на всяка мрежа за да се разбере, че базата данни е накъсана на малки парченца.

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

При разделната мрежова обработка това става още по-ефективно. Всеки възел още при създаването си се установява в определен раздел. Възлите попаднали в даден раздел обработват сделките за раздела. Изградената структура от данни бива навързвана към общата структура чрез изграждане на връзки към други раздели. Така се конструира общата структура на базата данни.

Както става ясно при този начин на обработка е необходимо да има външни за раздела възли, които да се грижат за връзките на разделите.

[filchef]

Какво е разделна обработка (sharding)?
-------------------------------------------------
"Sharding is a type of database partitioning that separates very large databases the into smaller, faster, more easily managed parts called data shards. The word shard means a small part of a whole."

Вид разделяне на база данни, при която се разделя много голяма база данни на малки парченца, за бързина, по-лесна обработка. Думата означава малка част от цялото.

При Radix Tempo, не става въпрос само за разделяне на базата данни на малки части. Това е лесно да се постигне и почти всички го правят. Достатъчно е да се погледнат данните на всяка мрежа за да се разбере, че базата данни е накъсана на малки парченца.

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

При разделната мрежова обработка това става още по-ефективно. Всеки възел още при създаването си се установява в определен раздел. Възлите попаднали в даден раздел обработват сделките за раздела. Изградената структура от данни бива навързвана към общата структура чрез изграждане на връзки към други раздели. Така се конструира общата структура на базата данни.

Както става ясно при този начин на обработка е необходимо да има външни за раздела възли, които да се грижат за връзките на разделите.

Май здраво се работи по тоя проект- ако решите и проблема с разпределяне на базата данни между отделните нодове може и да се замисля да рискувам някаква сума - как може човек да се включи във вътрешното ICO щом няма да има официално такова.

[danisapfirov]

Струва ми се, че този проблем е решен точно с разпределената обработка на данните.

Всяка услуга си има отделна база данни. Например услугата Radix Tight (Децентрализирания Чат) е отделна "блокверига" от данни отделена и обработваща само чат заявките. Тези данни не са смесени с данните имащи отношение към изпращането и получаването на койни по портфейлите и другите услуги на мрежата.

Ако някой реши да участва като възел (нод) обслужващ дадена услуга, той ще трябва да избере услуги и съответно ще натовари цялата "блокверига" от данни, която я обслужва. (Тук блокверига е само метафора за яснота ).

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

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

Съответно популярните услуги ще бъдат най-натоварените и там ще има най-много транзакции. От там и стимула за преориентация на възлите към тези услуги. Всичко това e динамичен пазар и сигурно ще бъде видимо и лесно за ориентация. Съответно собствениците на възли ще се преориентират по същия начин както миньорите при POW мрежите и ще пренасочват възела обслужващ мрежата към по-печелившите услуги.

Така разпределената обработка (sharding) би трябвало да решава въпросите свързани с големината на базата данни и разпределението на изчислителните ресурси както хоризонтално така и вертикално.

Съществуващите системи имат само хоризонтално мащабиране чрез DAG файл, а при Radix има мащабиране както по хоризонталата така и вертикално.
Това е истинското решение на проблема с мащабирането според разработчика.
Без специализиран хардуер, без ограничение на изчислителните ресурси (всеки с каквото има), без тесни места при хоризонталното и вертикалното мащабиране и без Off-chain частни мрежи изградени върху публичната инфраструктура.

Според начина на проектиране на мрежата не се очертават тесни места. Обещанието е да няма проблем нито с размера на базата данни, нито със скоростта на изчисленията... Дано и тестовете го потвърдят на практика.

[danisapfirov]

Относно вътрешното ICO, срока изтече на 31 окт и няма да има.
Следващата възможност е при публичното стартиране на мрежата според интереса и личната преценка.

[eddy]

Тъкмо мислех да питам за повече яснота относно това "sharding" и ето, че всичко е обяснено в подробности. Много благодаря за инфото, отново!

[danisapfirov]

Някои примери за проекти с разделна обработка (sharding)
1. Ethereum Plasma, 2. BTC LN, 3. Iota Tangle, 4. ARDOR и 5. Radix
-----------------------------------------------------------------------------------
Ethereum Plasma също ще върви към мащабиране чрез sharding.
Там Виталик Бутерин предлага друга схема с поднива от блоквериги.
Бързи блоквериги ще водят аналитичното осчетоводяване и ще бъдат изнесени извън основната блокверига, а синтетичните данни ще бъдат само в основната блокверига. Нивата могат да бъдат много, в зависимост от броя транзакции които трябва да се обработят.
Ако ще трябва да се обработят 5000 транзакции в сек, ще са налага да се създадат много нива от изнесени блоквериги, които да работят паралелно и да представят последователно данните на по-базовите нива, те на по-надолу и така до най-основната блокверига достигат само синтетични данни.
Много сложна схема.
Има аналогия с плазма, където най-горе е най-горещо и се поемат всички транзакции, а долу е основата.

При BTC мрежата смятат да се приложи разделната обработка (sharding) чрез технология наречена Lightning Networks. Там върху публичната блокверига на биткойна ще се изгради горен слой, който ще осигурява канали за разплащане. Плаща се даден канал (не на миньорите) и с този вече платен канал се правят много плащания.
Например имаш канал към Иван, който струва 25 долара. Той е отворен за една година и маже да му плащаш колкото пъти искаш за този период с висока скорост.

Очевидно тук проблема е че не си свободен да превеждаш койни на всеки адрес, а първо трябва да си платиш за канал. Миньорите не печелят нищо от отварянето на канали и очаквания повишен брой сделки в мрежата. Те печелят само от таксите от сделките в блока плюс намаляващата през 4 години награда за открит блок. Бизнеса им загива.

Много хора вярват, че тази схема ще отвори пътя на BTC към мащабируемост, но недостатъците й изглеждат очевидни.
1. Публичната BTC мрежа става частна нагоре
2. Таксите от вертикалното мащабиране отиват в частна компания и Биткойн мрежата се приватизира
Недоволните от това развитие вече се организираха за да запазят публичния характер на мрежата в BCH, BTG и B2X.

Iota Tangle е друга мрежа, която ще опита да направи разделна обработка и постигне мащабируемост.

NXT също реши да опита с проекта ARDOR, като направи разделна обработка чрез успоредни блоквериги. Резултатът от това усилие ще го видим след 1 Яну 2018 и от сега маже да се каже, че няма да повиши скоростта на сделките в даден канал. Там много блоквериги ще работят паралелно, а основното ARDOR ще осигурява синхрона. Тази концепция е от много паралелни бавни канали от блоквериги. Иновацията не е най-оригинална.

5. Radix към момента относно разпределената обработка:
Проблема е в пропускливостта на базата данни да добави огромното количество потоци от транзакции. Търси се DB Engine или специфично решение, което да издържи на натоварването.

Дан Хюз за плановете на ETH и последно за проблема с базата данни.

[danisapfirov]

Radix Цена и количество
-------------------------------

Laszlo Molnarfi said: ↑
I have a question, don't know whether this has been answered before:
What is the incentive for people to invest in Radix if the price is pegged (relatively stable)? For example, they buy in the ICO, and after the coin gets released : the price stays the same, since it is made to be stable. Is it cheaper in the ICO?

[BG] Какъв е стимула на хората на инвестират в Radix, ако цената е относително стабилна?

Peachy:
Gonna repeat this as it's worth repeating:
There are 2 levers in any currency or commodity: price and quantity
If I have a Qty 2 of something that are $1/each then my portfolio value = $2
That's the same as if I had Qty 1 of something priced at $2/each.
With Bitcoin and pretty much all fixed-supply (i.e. quantity) coins you are dealing with the "price" lever to reflect portfolio value and growth.
With Radix the quantity expands while the price lever stays (fairly) flat.
Thus, as new supply gets added to your wallet your portfolio value increases. Therefore, the incentive would be to get into the system earlier during the growth curve so that you can increase the quantity you receive as inflation happens.

[BG] Ще го повторя, понеже си заслужава да се каже отново.
Ако имаш количество 2 от нещо което струва 1 долар имаш нещо на стойност 2 долара.
Това е същото да имаш количество 1 на цена 2 долара.
При BTC доставката е фиксирана и там варира цената като стойността са дължи на промените в цената.
При Radix количеството, което имаш в портфейла нараства, а цената е стабилна. От тук идеята да влезеш
рано в играта за да започне растежа на количеството заради инфлацията от емитирането на нови жетони.

[danisapfirov]

Относно набирането на публичен капитал
-----------------------------------------------------

Изглежда, че начина по който Виталик Бутерин вижда набирането на капитал съвпада с избора на Radix
https://team.radix.global/files/hbnctpn ... LZfhzZl4DE

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

Най-добрия начин е набирането да става на етапи. Radix минаха през четири етапа. През тях хората виждат напредъка
на проекта и могат да подкрепят или не следващите стъпки. Би трябвало да има механизъм и за възстановяване
на средствата. Същото стана и с Radix. Имаше вложители, които не искаха да чакат повече и си поискаха
обратно вложените средства. Съответно те бяха възстановени.

[danisapfirov]

От устата на коня:
Масивно B-TREE задръстване в базите данни
Radix тестовете за скорост удрят ограничение !!!
---------------------------------------------------------------

been working on improving the ledger sync throughput this week
the shard testing showed up some issues with Berkeley DB
massive B-TREE bloat
spent all week trying out different DB engines...all have the same problem and are over complicated

so spent the past 24 hours throwing together a basic Key-Value store designed to leverage the characteristics of ledger data
just done the first test...its very un-optimized and bearing in mind I've never written a DB from scratch before, let alone in 24 hours....I've just managed to insert 10M random atoms in 630 seconds (on a platter drive no less)
thats 15,800 atoms per second to the DB
Berkeley was managing about 3,000 and it slowed over time

Ive got to do a bit more work on it yet, build a write ahead log for better durability and improve the checksum engine, so that 15k will drop a bit
but I should be able to claw some of it back with optimisations
I'll be very happy with 10k+ per second to a platter drive using < 1GB RAM for indexes (edited)
hmm maybe I'll test an SSD before bed....

running now
on an SSD Berkeley could manage about 6k/s random inserts

35,580 inserts per sec
so about double the platter throughput atm

thats single threaded too lol
heh at that pace could sync BTC from scratch in just under 2 hours lol

‎08‎:‎12‎ ‎AM
right, im going to bed
night

[danisapfirov]

Собствена VamosDB ще се опита да реши проблема с B-Tree блокажите
--------------------------------------------------------------------------------------------

Dan обяви, че вече е създал не-оптимизирана собствена база данни наречена Vamos, която да реши
проблема с пропускливостта на базите данни работещи с Radix Tempo.

За да се стартира следващия тест със скорост 10К+ tx/s и тази скорост да е устойчива, без да се стига до
запушване на двоичното дърво е необходимо специфично решение, което базите данни за обща употреба нямат.
Налага се колелото да се преоткрие след като тестовете с цял спектър от бази данни не показаха добри резултати.

Не са имали втори индексен курсор, или са ползвали B-Trees или LST или някаква друга структура за индексиране
която работи с O(log n) време (означава, че се забавя с добавянето на още данни).

Използваната да този момент BerkeleyDB има едно от най-бързите BTree дървета, но над 1 милиард атома, случайното откриване и обработка само на 1000 атома НЕ намерени в индекс кеша отнема 10+ секунди.

https://www.youtube.com/watch?v=EyX0rnk ... be&t=1m28s