Steemit Whitepaper translated into Bulgarian ! Steemit Whitepaper преведена на български ! Part 7

patelincho (67)in #steem • 7 years ago

Steemit Whitepaper translated into Bulgarian ! Steemit Whitepaper преведена на български ! Part 7

Bandwidth Instead of Micropayment Channels

The solution to the problems with micropayments is in implementing dynamic fractional reserves. Under this model the blockchain will automatically adjust the reserve ratio for the network during times of congestion. The blockchain will set a target utilization that leaves enough headroom for short term surges in demand. Any time the surges are sustained the blockchain reduces the maximum bandwidth-per-share. When a surge is over and there is surplus capacity the blockchain can slowly increase the bandwidth-per-share

Bandwidth used by an individual user should be measured over a suitably long period of time to allow that user to time-shift their usage. Users tend to login, do many things at once, then logout. This means that their bandwidth over a short period of time may appear much higher than if viewed over a longer period of time. If the time window is stretched too far then the reserve ratio will not adjust fast enough to respond to short-term surges, if the window is too short then clustering usage will have too big of an impact on normal users

In our estimate it should be sufficient to measure the average weekly bandwidth usage of users. Every time a user signs a transaction, that transaction is factored into their own individual moving average. Any time a user’s moving average exceeds the current network limit their transaction is delayed until their average falls below the limit.

Ширина на честотната лента вместо микропроцесорни платежни канали

Решаването на проблемите с микроплащанията е в осъществяването на динамични фракционни резерви. При този модел блоковата верига автоматично ще коригира резервния коефициент за мрежата по време на претоварване. Блокверигата ще определи целево използване, което оставя достатъчно място за краткосрочно нарастване на търсенето. Всеки път, когато ударите се запазят, блок-веригата намалява максималната честотна лента на акция. Когато прекосяването приключи и има излишен капацитет, блок-веригата може бавно да увеличи честотната лента на акция

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

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

Example Implementation

Let B equal a user’s average bandwidth at time T. Let W equal the number of seconds per week, and let N equal the size of the new transaction that occurred S seconds after T. Given this information the blockchain can calculate the new average bandwidth for a user as:

Bnew = MIN(0,B * (WS) / W) + N * S / W Tnew = T + S

Each user is entitled to an average weekly bandwidth of:

Let U = the user’s SP

Let S = the total number of SP

Let R = the current reserve ratio between 1 and Rmax

Let C = the maximum block size capacity set by witnesses

Let L = the total blocks per week

Let M = C * L * R Allocation = M * U / S

A user would be entitled to an average bandwidth of M * U / S. Any time a transaction would cause the user’s average to go above this threshold they would be unable to transact until enough time passes to lower the average.

The network can increase the reserve ratio, anytime blocks are less than half the target capacity and decrease it anytime they are more than half. The algorithm used to adjust R is designed to react quickly to decrease the reserve ratio when there is a surge in demand, while acting slowly to increase the reserve ratio in period of low demand.

The minimum reserve ratio is 1, and the maximum reserve ratio should be calculated to prevent small stakeholders from consuming all of the available bandwidth. If no one is using the available bandwidth then the reserve ratio can grow until a user with just 1 satoshi of the currency is able to transact every single block.

Пример за внедряване

Нека B равна на средната пропускателна способност на потребителя в момент Т. Нека W е равен на броя секунди на седмица и нека N е равен на размера на новата транзакция, която е настъпила S секунди след Т. Като се има предвид тази информация, блокът може да изчисли новата средна честотна лента за Потребител като:

Bnew = MIN(0,B * (WS) / W) + N * S / W Tnew = T + S

Всеки потребител има право на средна седмична честотна лента от:

Let U = the user’s SP

Let S = the total number of SP

Let R = the current reserve ratio between 1 and Rmax

Let C = the maximum block size capacity set by witnesses

Let L = the total blocks per week

Let M = C * L * R Allocation = M * U / S

Потребител ще има право на средна честотна лента от M * U / S. Всеки път, когато транзакцията доведе до това, че средната стойност на потребителя надхвърли този праг, те няма да могат да извършват сделка, докато не мине достатъчно време, за да се намали средната стойност.

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

Коефициентът на минималните резерви е 1, а максималният коефициент на резерви трябва да бъде изчислен, за да не позволи на малките заинтересовани страни да консумират цялата налична честотна лента. Ако никой не използва наличната честотна лента, тогава коефициентът на резерви може да нарасне, докато един потребител със само 1 satoshi на валутата е в състояние да извършва превод на всеки един блок.

Case Study: Bitcoin

To understand how this algorithm would work on Bitcoin it is necessary to estimate a reasonable value for the reserve ratio, R, based on actual usage. Based upon the total supply of 15M BTC and a daily transaction volume of 400K BTC , we can derive a minimum reserve 10 ratio of 38 for Bitcoin. Using the equations we can calculate the weekly bandwidth (in bytes) allowed per BTC to be:

Let C = 1MB = 1024*1024

Let L = 1008 (blocks per week)

Let R = 38

Let S = 14000000 BTC (supply minus Satoshi’s unmoving coins)

Let U = 1 BTC CLR/S = 2869 bytes per week, or about 5 transactions/week per BTC

CLR/S = 2869 bytes per week, or about 5 transactions/week per BTC

Since R = 38 is a lower bound on the reserve ratio, CLR/S is a lower bound on the permitted bandwidth. This simple case study suggests a user will require at most 0.20 BTC (over $80 as of this writing) to transact once per week. However, this is a loose upper bound derived from the assumption that all BTC are equally mobile. This is not the case -- users with dozens or hundreds of bitcoins do not necessarily transact dozens or hundreds of times a week! The “leftover” transactions that those users “should” have made will increase the reserve ratio, allowing their unused bandwidth to be “recycled” for smaller users.

All of the above estimates are conservative upper bounds assuming coins and usage are distributed in a relatively flat manner. The reality is that heavy users, such as exchanges, have a much higher coin-to-usage ratio than lighter users, which in turn means that actual minimum balance requirements are far lower.

Казус: Bitcoin

За да разберем как този алгоритъм ще работи върху Bitcoin, е необходимо да се оцени разумна стойност за съотношението на резервите, R, въз основа на действителното използване. Въз основа на общото предлагане на 15M BTC и дневен обем на сделката от 400K BTC, можем да извлечем съотношение за минимален резерв 10 за 38 за Bitcoin. Използвайки уравненията, можем да изчислим седмичната честотна лента (в байтове), която е разрешена за БТК, да бъде:

Let C = 1MB = 1024*1024

Let L = 1008 (blocks per week)

Let R = 38

Let S = 14000000 BTC (supply minus Satoshi’s unmoving coins)

Let U = 1 BTC CLR/S = 2869 bytes per week, or about 5 transactions/week per BTC

CLR/S = 2869 bytes per week, or about 5 transactions/week per BTC

Тъй като R = 38 е долната граница на резервното съотношение, CLR / S е долната граница на допустимата широчина на честотната лента. Това просто проучване на случая предполага, че потребителят ще изисква най-много 0,20 БТК (над 80 щ.д. ) да извършва транзакции веднъж седмично. Това обаче е свободна горна граница, произтичаща от предположението, че всички БТК са еднакво мобилни. Това не е така - потребителите с десетки или стотици bitcoins не е задължително да извършват сделки десетки или стотици пъти седмично! Остатъчните транзакции, които тези потребители трябваше да направят, ще увеличат съотношението на резервите, като позволят неизползваната им честотна лента да бъде "рециклирана" за по-малките потребители.

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

Impact of Capacity

Blockchain capacity isn’t necessarily capped. It is well within the technological capability of internet infrastructure to increase the Bitcoin block size to 10MB which in turn will reduce the minimum required balance by a factor of 10. While Bitcoin currently supports about 3 transactions per second, alternative implementations are capable of over 1000 transactions per second. This changes our conservative upper bound to 0.0006 BTC or about $0.25, meaning that an account holding $0.25 would be able to transact at least once per week on average (and likely many more times because we’re dealing with a fairly loose upper bound).

Влияние на капацитета

Капацитетът на блоковете не е задължително ограничен. В рамките на технологичната способност на интернет инфраструктурата е да се увеличи размерът на блока Bitcoin до 10 МБ, което на свой ред ще намали минималния задължителен баланс с коефициент 10. Докато Bitcoin понастоящем поддържа около 3 транзакции в секунда, алтернативните реализации могат да надхвърлят 1000 Транзакции в секунда. Това променя нашата консервативна горна граница до 0.0006 БТК или около $ 0.25, което означава, че една сметка, която държи $ 0.25, ще може да извършва транзакции поне веднъж седмично средно (и вероятно много повече пъти, защото имаме доста свободна горна граница).

Maximum Number of Unique Users

We can use similar math to calculate the maximum number of unique users that the network can allow to transact once per week as: B*W/T. T represents the average transaction size. This means Bitcoin could support about 2 million users transacting once per week assuming each user had an equal balance.

Максимален брой уникални потребители

Можем да използваме подобна математика, за да изчислим максималния брой уникални потребители, които мрежата може да позволи да извършва транзакции веднъж седмично като: B * W / T. T представлява средния размер на транзакцията. Това означава, че Bitcoin може да поддържа около 2 милиона потребители, които извършват транзакции веднъж седмично, като приема, че всеки потребител има равновесие.

Comparison to Fees

If we assume a user with $25 dollars worth of BTC transacts once per week and pays a $0.04 cent fee each time then they would pay over $2.00 in fees per year. A user would have to earn a 8% rate of return on their $25 dollars just to break even with paying fees. Chances are that users were going to hold their money on the blockchain anyway, so this user with $25 worth of BTC just saved $2 over the course of a year by adopting a rate-limiting approach rather than a fee-based approach. With just $175 they could transact every single day and save $14 per year

Сравнение на таксите

Ако приемем, че BTC сключва сделки веднъж седмично с потребител на стойност 25 долара и плаща такса от 0.04 цента всеки път, те плащат над $ 2.00 такси годишно. Потребителят ще трябва да спечели 8% от доходността на своите $ 25 долара, само за да се справи дори и с плащането на такси. Шансовете са потребителите да държат парите си на блокада, така че този потребител с 25 щ.д. на БТК просто спести $ 2 в течение на една година, като приеме подход за ограничаване на лихвения процент, а не подход, базиран на такси. Само с $ 175 биха могли да сключват сделки всеки ден и да спестят 14 долара годишно

Account Creation

Steem’s account-based system with publicly known balances simplifies the implementation of the bandwidth-based rate limiting algorithm. Any account with a balance below the minimum required to transact once per week would be unable to transact. This implies that all new accounts should be funded with at least this minimum balance. It also implies that users wishing to transact in smaller amounts can, so long as they hold a larger balance and reuse the account.

It is possible for a low-balance account created during a time of low usage to become inaccessible if the network usage picks up. The funds could be recovered at any time by transferring a larger balance into the account.

In order to maintain a reasonable user experience with a minimum number of hung accounts, all new accounts should start out with a balance 10 times the minimum required to transact weekly. This way even if demand increases by a factor of 10 the account will remain viable.

Any initial account balance would have to come from the user creating the account and not from token creation due to the potential for sybil attacks.

Account Creation

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

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

За да се поддържа разумният потребителски опит с минимален брой закачени сметки, всички нови профили трябва да започнат с баланс 10 пъти по-голям от минималния минимум, необходим за извършване на сделки седмично. По този начин, дори ако търсенето се увеличи с коефициент 10, сметката ще остане жизнеспособна.

Всяко първоначално салдо по сметката би трябвало да дойде от потребителя, създаващ профила, а не от създаването на символи, поради възможността за атаки на сибил.