paper.txt 100 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562156315641565156615671568156915701571157215731574157515761577157815791580158115821583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640164116421643164416451646164716481649165016511652165316541655165616571658165916601661166216631664166516661667166816691670167116721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721172217231724172517261727172817291730173117321733173417351736173717381739174017411742174317441745174617471748174917501751175217531754175517561757175817591760176117621763176417651766176717681769177017711772177317741775177617771778177917801781178217831784178517861787178817891790179117921793179417951796179717981799180018011802180318041805180618071808180918101811181218131814181518161817181818191820182118221823182418251826182718281829183018311832183318341835183618371838183918401841184218431844184518461847184818491850185118521853185418551856185718581859186018611862186318641865186618671868186918701871187218731874187518761877187818791880188118821883188418851886188718881889189018911892189318941895189618971898189919001901190219031904190519061907190819091910191119121913191419151916191719181919192019211922192319241925192619271928192919301931193219331934193519361937193819391940194119421943194419451946194719481949195019511952195319541955195619571958195919601961196219631964196519661967196819691970197119721973197419751976197719781979198019811982198319841985198619871988198919901991199219931994199519961997199819992000200120022003200420052006200720082009201020112012201320142015201620172018201920202021202220232024202520262027202820292030203120322033203420352036203720382039204020412042204320442045204620472048204920502051205220532054205520562057205820592060206120622063206420652066206720682069207020712072207320742075207620772078207920802081208220832084208520862087208820892090209120922093209420952096209720982099210021012102210321042105210621072108210921102111211221132114211521162117211821192120212121222123212421252126212721282129213021312132213321342135213621372138213921402141214221432144214521462147214821492150215121522153215421552156215721582159216021612162216321642165216621672168216921702171217221732174217521762177217821792180218121822183218421852186218721882189219021912192219321942195219621972198219922002201220222032204220522062207220822092210221122122213221422152216221722182219222022212222222322242225222622272228222922302231223222332234223522362237223822392240224122422243224422452246224722482249225022512252225322542255225622572258225922602261226222632264226522662267226822692270227122722273227422752276227722782279228022812282228322842285228622872288228922902291229222932294229522962297229822992300230123022303230423052306230723082309231023112312231323142315231623172318231923202321232223232324232523262327
  1. Joystream: A Protocol for User Governed Content
  2. Platforms
  3. Jsgenesis
  4. June 8, 2020
  5. DRAFT Version 0.1
  6. Abstract
  7. T
  8. The Joystream protocol attempts to formalize a content platform that is governed and operated by
  9. the platform users. The centerpiece of the protocol is the shared platform state, implemented on top of
  10. a blockchain consensus system, which coordinates and provides incentives to all stakeholders. Almost
  11. DR
  12. AF
  13. every aspect of a content platform is endogenous to the protocol, including
  14. (a) governance
  15. (b) membership system, with screening and policing
  16. (c) storage and distribution
  17. (d) curated content directory
  18. (e) content search, browsing, and recommendations
  19. (f) software development finance and coordination
  20. (g) content production financing
  21. (h) advertising auctions and placement
  22. (i) communication: messaging and message boards
  23. and every subsystem is fully accountable to, and directed by, the users, as represented by the governance system. Capturing such a broad range of systems in the protocol is the distinguishing characteristic
  24. of this proposal. It is motivated by the thesis that a high level of platform accountability can be achieved
  25. by empowering two user capabilities.
  26. First, the ability to voice discontent and subsequently implement changes based on such voices, which
  27. relies on an immutable history of actions, reliable information sharing, and binding execution of policy
  28. changes.
  29. Second, the ability to exit the platform at a low cost and create an alternative when the platform
  30. decay has gone too far. This relies on having the entire platform state available for wholesale replication,
  31. which is not possible if critical parts of the platform state are exogenous to the protocol.
  32. Contents
  33. 1 Preface
  34. 4
  35. 1
  36. 2 Introduction
  37. 4
  38. 2.1
  39. Motivation
  40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  41. 4
  42. 2.2
  43. Joystream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  44. 4
  45. 3 Notes
  46. 5
  47. 4 Blockchain
  48. 5
  49. 4.1
  50. Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  51. 6
  52. 4.2
  53. Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  54. 7
  55. 4.3
  56. Asynchronous Transaction Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  57. 8
  58. 4.4
  59. Fee Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  60. 8
  61. 4.4.1
  62. Models
  63. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  64. 8
  65. 4.4.2
  66. BRAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  67. 9
  68. Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  69. 9
  70. 4.5
  71. T
  72. 5 Accounts and Tokens
  73. 6 Member
  74. 10
  75. 11
  76. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  77. 6.2
  78. Member, Profile and Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  79. 11
  80. 6.3
  81. Paid Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  82. 12
  83. 6.4
  84. Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  85. 13
  86. DR
  87. AF
  88. 6.1
  89. 11
  90. 7 Roles, Staking and Slashing
  91. 14
  92. 8 Rewards
  93. 14
  94. 9 Governance
  95. 9.1
  96. 9.2
  97. 9.3
  98. 14
  99. Council . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  100. 14
  101. 9.1.1
  102. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  103. 14
  104. 9.1.2
  105. Elections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  106. 15
  107. 9.1.3
  108. Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  109. 16
  110. Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  111. 16
  112. 9.2.1
  113. Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  114. 16
  115. 9.2.2
  116. Life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  117. 16
  118. Working Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  119. 17
  120. 9.3.1
  121. Leads and workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  122. 18
  123. 9.3.2
  124. Installing, replacing, and evicting leads
  125. 18
  126. . . . . . . . . . . . . . . . . . . . . . . . . . .
  127. 10 Membership Screening and Curation
  128. 18
  129. 10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  130. 18
  131. 10.2 Working groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  132. 19
  133. 10.3 Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  134. 19
  135. 10.4 Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  136. 20
  137. 2
  138. 10.5 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  139. 11 Data storage and distribution
  140. 20
  141. 20
  142. 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  143. 20
  144. 11.2 Working Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  145. 21
  146. 11.3 Storage providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  147. 21
  148. 11.4 Distributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  149. 23
  150. 11.5 Data directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  151. 23
  152. 11.6 Uploading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  153. 25
  154. 11.7 Downloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  155. 26
  156. 11.8 Entry, exit, and distribution policy updates . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  157. 27
  158. 11.9 Policing and data removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  159. 27
  160. 11.10Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  161. 27
  162. 12 Content directory
  163. 27
  164. 27
  165. 12.2 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  166. 27
  167. 12.3 Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  168. 28
  169. 12.4 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  170. 28
  171. 12.5 Disputes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  172. 29
  173. 12.6 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  174. 29
  175. 13 Discovery
  176. DR
  177. AF
  178. T
  179. 12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  180. 29
  181. 13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  182. 29
  183. 13.2 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  184. 29
  185. 13.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  186. 29
  187. 13.4 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  188. 30
  189. 14 Software development
  190. 30
  191. 14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  192. 30
  193. 14.1.1 Financing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  194. 30
  195. 14.1.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  196. 30
  197. 14.1.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  198. 31
  199. 14.2 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  200. 31
  201. 14.3 Project
  202. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  203. 31
  204. 14.4 Artifacts, reproducible, and releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  205. 32
  206. 14.5 Automated testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  207. 32
  208. 14.6 Deployment and upgradeability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  209. 32
  210. 15 Content finance
  211. 33
  212. 15.1 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  213. 33
  214. 15.2 Project life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  215. 33
  216. 3
  217. 16 Advertising
  218. 34
  219. 16.1 Working group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  220. 34
  221. 16.2 Surfaces and targeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  222. 34
  223. 16.3 Campaigns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  224. 35
  225. 16.4 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  226. 35
  227. 16.5 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  228. 36
  229. 17 Miscellaneous
  230. 36
  231. 17.1 Resolving hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  232. 18 Discussion
  233. 1
  234. 36
  235. 36
  236. Preface
  237. T
  238. This document aims to give a high level overview of the design approach for of a new protocol for content
  239. platforms. This is an evolving document meant as a basis for an iterative review, technical specification
  240. and testing, and revised versions will be developed on the basis of that process. Multiple aspects of the
  241. DR
  242. AF
  243. protocol are still subject to active research, and any part of the current design may be amended or entirely
  244. abandoned as a result of subsequent considerations. Lastly, the descriptive resolution varies substantially
  245. across the proposal as a result of different parts at radically different levels of maturity.
  246. 2
  247. Introduction
  248. 2.1
  249. Motivation
  250. Due to a mixture of conspiring factors, such as platform externalities, economies of scale and, jurisdictional
  251. arbitrage, dominant contemporary Internet platforms have become some of the least accountable organizations today. The traditionally constraining institutions of market competition, regulation and litigation
  252. simultaneously appear to be unable to push back against their market power. The social cost of this equilibrium is multifaceted, leading to lower innovation, platform rents, and more broadly to the fact that platform
  253. policy is only incidentally, not primarily, guided by the objectives of the largest platform stakeholder: users.
  254. Users should be broadly understood as anyone who is participating on a platform in any capacity.
  255. 2.2
  256. Joystream
  257. The Joystream protocol is an attempt at formalizing the structure and function of a content platform, where
  258. user accountability is a key objective and organizing principle. This accountability is generated by technically
  259. codifying two well-known complementary responses to organizational decline [1].
  260. - Voice
  261. Users have effective means of sharing information, coordinating, and reaching decisions about key
  262. collective action problems, namely how to allocate and regulate the use of any shared platform asset.
  263. 4
  264. - Exit
  265. Users have effective means of creating new platform instances that can preserve the entire platform
  266. history and state. This ability to fully replicate the technical, administrative, and economic state of a
  267. platform has two positive effects on accountability: first, it empowers the voice of users through the
  268. threat of a low cost exist; and second, it supports the emergence of a diversity of platforms when the
  269. underlying interests of stakeholders are irreconcilably incompatible or where the organizational decline
  270. as gone sufficiently far.
  271. In order to build in the capacity for such responses, the Joystream protocol is built as follows. The shared
  272. platform state lives on an open blockchain consensus system. As a result, it has a public state and history
  273. that is fully auditable and immutable. The protocol also has secure direct and broadcast communication
  274. capabilities integrated within a platform identity system. This means that it is very cheap for any participant
  275. to securely inspect the system and make irrefutable positive claims as part of subsequent public deliberation,
  276. learning, debating, or agitating. The identity system along with an immutable history of public actions and
  277. T
  278. communications generates the incentive to invest in community standing and act with a long time horizon.
  279. Further, there is a governance mechanism that allows low cost coordination around the use and regulation
  280. of shared assets and the amendment of the protocol. Importantly this mechanism self executes and thus
  281. DR
  282. AF
  283. provides reliable and a counterparty-free implementation of governance decisions. All these properties work
  284. in hand to support voice as response.
  285. The protocol itself is open and implemented in open source reference software. It has an open shared
  286. state and data accessible for all. This makes the copying step of creating an alternative instantiation trivial
  287. and thus supports exit as response.
  288. 3
  289. Notes
  290. Occasionally, there may be reference to data types in various schemes or concept definitions, assume the
  291. C++ type system.
  292. When identifier fields are used in definitions, assume that they are unique and created by auto-incrementation
  293. in the context of some set of existing instances.
  294. Constant values are displayed with a capitalized snake case as follows:
  295. . These are values that
  296. FOO BAR
  297. cannot be changed through governance and require a hard fork or consensus upgrade. In some occasions,
  298. the symbol
  299. 4
  300. C
  301. is used to denote some constant that is specific to the context.
  302. Blockchain
  303. The Joystream protocol is stateful, and the infrastructure for the secure distribution and updating of this
  304. state is a blockchain system. A given instantiation of the Joystream protocol runs on its own single-purpose
  305. blockchain infrastructure, which only processes transactions related to this instantiation. In the rest of
  306. the document, this blockchain will be treated as a silent transaction ordering mechanism; however, in the
  307. following section, it will briefly describe the assumptions on the blockchain infrastructure in the protocol
  308. design. Here, and in the rest of the document, the platform or platform state will refer to the state upon
  309. which transactions operate. In Bitcoin, for example, this would be the UTXO set and be distinctive from
  310. 5
  311. the state of the underlying blockchain infrastructure itself, namely the actual chain of blocks designated by
  312. the chain selection rule.
  313. 4.1
  314. Consensus
  315. The blockchain has a consensus algorithm in the classical BFT algorithm family that is adapted to use
  316. Proof-of-Stake-based voting power for a dynamic validator1 set. A designated platform token, described
  317. further in section 5, is used by the validators to stake and is also the unit in which they are rewarded. There
  318. is a growing set of such consensus protocols [2, 3, 4], and the following general properties of these systems
  319. are of importance to the protocol design.
  320. - High throughput and low latency: In benchmarks, these algorithms have been shown to support combinations of confirmation latency, transaction throughput, validator count, and geographic
  321. distribution, which are substantially more attractive than that found in typical production Nakamoto
  322. T
  323. consensus chains [5].
  324. - Light client friendly: The overwhelming majority of end users will need to securely access the
  325. platform in computing environments with resource constraints, such as browsers and mobile devices.
  326. DR
  327. AF
  328. They should also be able to quickly start interacting with the platform, even if the last sign-on was a
  329. long time ago or may even be the first time. In addition, the Joystream protocol will have a large state
  330. and transaction history. These constraints make a light client protocol the only genuine interaction
  331. model for almost all users.
  332. In these algorithms, a light client only needs to track any potential changes in the validator set, which
  333. in practice changes quite infrequently, for example, due to the unbonding period induced delay and
  334. not in large increments. Once an up-to-date validator set is identified, the client can securely read any
  335. part of the platform state by authenticating merkle proofs from full nodes against state commitments
  336. found in the relevant block header.
  337. This is in contrast to Nakamoto consenus systems where all block headers starting at genesis2 must
  338. initially be downloaded, and one must keep up with new blocks as the system moves forward3 . Headers
  339. are validated, and the chain selection rule is applied on a continuous basis. Even if feasible, this requires
  340. a long initial synchronization period whenever a client comes on line for the first time or at some point
  341. after a hiatus.
  342. - Finality: The finality of block commitment is the property that once two-thirds of the current validator
  343. set has signed off on a block, then that block will become, and remain, part of the chain permanently.
  344. This is in contrast to Nakamoto consenus systems where the heaviest chain selection rule can in principle
  345. fork off any block, albeit with exponentially declining probability in the block depth, from the chain.
  346. This property has a number of critical benefits
  347. – Easy interoperability
  348. 1 We
  349. will refer to a block producing actor as a validator, and anyone simply fully validating the chain a full validator.
  350. reference, Ethereum has a chain of more than 7.1M blocks as of Jan. 22 2019.
  351. 3 For reference, Ethereum commits 5760 new blocks per day as of Jan. 22 2019.
  352. 2 For
  353. 6
  354. In order for secure assertions about the state of the Joystream chain to be feasible on a different
  355. chain, this chain will effectively need to behave as a light client that can track the most up-to-date
  356. committed block on the Joystream chain. Finality ensures that tracking this becomes very easy, as
  357. there are no reorganization events that can occur. Such events open up the possibility of reverting
  358. the basis critical state changes executed on the remote chain prior to the reorganization, e.g.
  359. changes in asset ownership. Dealing with this is complex and will often involve introducing delays.
  360. Moreover, the light client friendliness discussed above also helps in reducing the information to
  361. be submitted to the remote chain light client.
  362. – Safe launch and coexistence
  363. Finality ensures that the incentive to attack a chain to perform a double spend through a reorganization goes away. This risk is particularly high in the early stage of the lifetime of a new
  364. blockchain, as the initial amount of work (or stake) on the system may be particularly low. Even
  365. beyond the launch, the amount of value securing the system will always fluctuate, in particular
  366. T
  367. for nascent systems; thus, finality provides a valuable guarantee.
  368. – Better usability
  369. Finality makes it very easy to write applications that interact with the blockchain, as complex
  370. DR
  371. AF
  372. logic for gracefully dealing with reorganizations is entirely omitted. There is no need to introduce
  373. arbitrary security delay, which is also a benefit to end users.
  374. 4.2
  375. Upgrading
  376. It is possible to upgrade both the transaction validation rules and the current state of the chain through
  377. the transaction processing system itself. This can typically be enabled by storing the transaction validation
  378. rules in the state and then running them on top of some virtualization layer. This property is a requirement
  379. for the following:
  380. - Genuine accountability: Without a formalized mechanism for both measuring the preferences of
  381. stakeholders on collective action decisions and exercising those decisions, there will be an inevitable
  382. development of off-chain social conventions and authorities who will operate as stuarts and coordinators
  383. in such scenarios. Such actors are not accountable to platform stakeholders in any well defined or
  384. transparent way, which is undesirable in itself.
  385. - Faster iteration: For the protocol rules to quickly evolve, the process to coordinate around such
  386. changes must economize on critical ecosystem resources, such as attention, information processing, and
  387. legitimacy. Opaque off-chain upgrading processes risk becoming a perpetual source of conflict around
  388. questions of legitimacy. Moreover, the requirement for active upgrading of validator software and the
  389. non-committing signaling games that often surround such events are an additional practical friction.
  390. Instead, endogenous upgrading with an accompanying on-chain immutable record of deliberation and
  391. a history of such updates can offer an effective remedy against these difficulties.
  392. - Developer fungibility: In general, a complex system where any failure is catastrophic will require
  393. constraining the number of developers who can securely contribute to the improvement of the system.
  394. 7
  395. This constraint can in extreme cases support a market power in the hands of key developers, where
  396. they can end up becoming gate keepers for any change to be applied.
  397. In the context of upgrading blockchain systems, the reliance on off-chain upgrades to the consensus
  398. rules, the state transition function must incorporate the full history of rule sets from genesis to the
  399. most recent changes to validate all blocks. In practice, this ends up with a monotonically increasing
  400. complexity confronting developers wanting to comprehend and modify the system, which is problematic,
  401. as explained.
  402. 4.3
  403. Asynchronous Transaction Processing
  404. Certain types of transactions that may take a long time to process are occasionally required. Specifically,
  405. they may even require more time to process more than what is feasible when consuming all the the block
  406. times across multiple blocks. In some cases, it may be possible to accommodate such processing by the
  407. following approach, referred to as Asynchronous Transaction Processing (ATP). When the transaction is
  408. T
  409. processed, and is valid, an appropriate subset of the blockchain state is locked in the sense that all other
  410. transaction types that mutate it are considered invalid. In order to implement this in an orderly fashion,
  411. where it is practical to reason about what transactions are impacted by a given subset, one should confine
  412. DR
  413. AF
  414. the approach to suitable transaction types. Now, during this locking period, which typically will last for a
  415. predefined number of blocks, the validator nodes are free to conduct the desired processing for the initial
  416. transaction outside the normal sequential validation of blocks, for example, on a separate processing unit.
  417. The locking prevents any race condition. Finally, when the time has expired, the finalized processing result
  418. is committed to the blockchain state at the end of the corresponding block, and the substate locking is no
  419. longer in effect.
  420. 4.4
  421. Fee Model
  422. A standalone chain allows the freedom to implement a custom fee policy. Building on top of an existing
  423. chain would result in inheriting its existing fee model for on-chain capacity, which often is tied to generalized
  424. congestion control and financing security.
  425. 4.4.1
  426. Models
  427. There are two types of fee model modes available in the protocol.
  428. - Transactional: The normal transactional pay-per-use model can be found in a majority of currencyfocused systems such as Bitcoin. This mode applies to basic operations such as moving fund.
  429. - Block Range Action Quota (BRAQ): An action refers to a combination of an actor, role, and
  430. transaction type. This model prevents a given action from occurring more than a given number of
  431. times over a given number of blocks. Successfully issuing such transactions within the given limits does
  432. not involve marginal outlay for the given actor.
  433. Given that BRAQ will cover the majority of transactions, security will primarily be financed through
  434. minting tokens, which also more closely matches the public goods nature of chain security. This dual model
  435. has a number of critical benefits for platform.
  436. 8
  437. First, it drastically reduces the transactions costs of onboarding new users who initially have no tokens
  438. and either face prohibitive costs in acquiring, storing, and using them or need to be persuaded about the
  439. value of the platform before being willing to incur such costs. Such users will instead face the option of
  440. being onboarded via a screening mechanism (see section 10). After this, they will be able to immediately
  441. interact with the system, within constraints. Users may later earn or purchase tokens to escape quota
  442. limitations. Alternatively, the platform itself may simply eventually abandon the free policy once these costs
  443. have declined sufficiently as a result of general increase in maturity of the blockchain ecosystem.
  444. Second, this approach explicitly subjects the fee model to a dynamic governance process where all default
  445. limits and individual member quotas can be adjusted. This is an easy and possibly the only feasible long term
  446. mechanism for correcting the externalities associated with the long-term social cost of transaction processing
  447. and state utilization in public chains [6].
  448. 4.4.2
  449. BRAQ
  450. In the BRAQ model, two parameters are required for each action: the range length, denoted by R, and the
  451. T
  452. action quota, denoted by Q; both are positive integers. A combined range length and transaction limit is
  453. known as a BRAQ quota. This model prevents an action in a given block if there are already L such actions
  454. in the current R blocks prior. The system must maintain a sequence of positive integers H = (h1 , . . . , hN ),
  455. DR
  456. AF
  457. known as the event list, for each action, initially set to an empty list. A combination of BRAQ quota and
  458. such a list is referred to as BRAQ instance. An action should not be allowed in block height h when
  459. L ≤ |{hi | hi ≥ h − R for some i = 1, . . . , N }|
  460. otherwise it will proceed to normal validation. If the corresponding transaction is subsequently found to
  461. be accepted, then the new value for H should be
  462. (h, h1 , . . . , hM )
  463. where M = N if N < L, otherwise M = N − 1. Hence, H is a list of block heights for, up to, the last
  464. N successful actions. The benefit of the event list is that it makes it easy for a light client to track the
  465. availability of a given action at any given time, as the entire BRAQ instance is securely available in the
  466. state. A full node could in principle track and enforce an instance without having the H in the state.
  467. Lastly, when using this model, it is in some cases desirable to share the same quota across a range of
  468. instances. This is typically if you are dealing with a very large number of instances all of which have very
  469. similar actors. At the same time, it is also ideal to retain the flexibility to have explicitly custom quotas for
  470. specific actors based on policy or discretion. These two goals are accommodated by the concept of a BRAQ
  471. quota proxy. This is either a normal quota or an identifier resolving a normal quota in some context-specific
  472. pool of quotas or simply a sentinel to use some other context specific quota.
  473. 4.5
  474. Interoperability
  475. Some of the assets that are of value to the platform will inevitably not live in the state of the same blockchain.
  476. This can, for example, be the state of a DNS mapping that lives on some other system, such as ENS [7]
  477. or Handshake [8]. It may even be desirable to move certain assets from the Joystream blockchain, such as
  478. 9
  479. tokens, onto other blockchain systems. While proposals are being developed to support very general interblockchain transaction routinely, such as Cosmos [5] for tokens and Polkadot [9], it is not clear when or if
  480. they will be fully deployed, and to what extent the Joystream blockchain will be able to benefit, or more
  481. simply whether the Joystream governance process will converge on such an integration.
  482. A direct and simple case-by-case integration will be possible by using the same standard technique in
  483. almost all secure blockchain integration proposals. For each blockchain that needs to be integrated with
  484. Joystream, deploy a light client instance on each side, for the opposite side, where there is a requirement
  485. to write to the state on the first. This obviously requires that the given side is expressive and economical
  486. enough to support such an on-chain light client. Take the example of wanting to subject an ENS mapping,
  487. on Ethereum, to the governance processes on the Joystream blockchain. This will only require deploying a
  488. Joystream light client contract on Ethereum, which also is set as the owner to the given mapping. Block
  489. headers committed to the Joystream blockchain will then have to be submitted to this light client, at the
  490. very least when there are changes in validator sets. A designated party from the Joystream side can be
  491. incentivised to regularly conduct this. This header history in the state of the contract will allow it to
  492. T
  493. be securely convinced of the ENS-related signaling actions on the Joystream side through Merkle proofs,
  494. since these will be committed to in the corresponding headers4 . The contract can then in turn execute the
  495. 5
  496. DR
  497. AF
  498. corresponding on-chain contract call to put this signal into effect in ENS.
  499. Accounts and Tokens
  500. The platform has a standard for account-based (fungible) token ownership. There will be a primary token,
  501. called the native token, which will be part of the initial state of the platform. This native token will, as will
  502. be described later, be used for value transfer, bonding, and governance activities.
  503. New tokens are minted continuously for a very wide range of purposes, all primarily to reward some
  504. actor for some behavior. This minting is perpetual, and how much is minted for what purpose is controlled
  505. by the platform governance process. New tokens are also burned by actors in scenarios where they need to
  506. contribute to the platform through the token; e.g. purchasing ad placements. There is no platform treasury
  507. that will otherwise absorb these tokens. As a result of these three separate exogenous dynamics - and the
  508. platform upgradeability functionality, there is no ex-ante certainty about the total supply of the token at
  509. different points in time in the future.
  510. The other tokens are related to the content finance market, described further in section 15. They are
  511. issued by publishing a token profile into a registry called the token registry. A token profile includes key
  512. information, such as a standard token symbol, issuer identifier, description, and also the ownership state itself
  513. known as the token balances. The token balances simply maps a public key to a positive integer, and a single
  514. mapping represents the quantity of tokens under the control of whoever holds the private key corresponding
  515. to the public key. The registration of a key in the balances of a token is referred to an account. Reuse of the
  516. same key pair across accounts for the same actor is an individual policy choice. Normal spending operations
  517. can be conducted from an account to any new or existing account on the same token by signing a message
  518. with a private key that matches the public key corresponding to the original account. The token registry
  519. is a mapping from a token identifier, which is a unique positive integer, to the corresponding token profile.
  520. 4 This
  521. could be in the event logging system, or individual transaction types being included in blocks.
  522. 10
  523. The native token has identifier 0.
  524. Note that the following account model is distinct from the smart contract account model in general,
  525. where all transactions are tied to a given account, although such platforms also have an account-based token
  526. ownership model. Transactions are instead on Joystream, at least most of the time, tied to membership,
  527. which has been explained in further detail in section 6.
  528. 6
  529. 6.1
  530. Member
  531. Overview
  532. The membership concept is meant to unify all platform-level participation for the same actor in a way that
  533. is independent of token ownership in the account system. This means that all platform level actions are
  534. with reference to a particular membership. A given member may of course occupy a range of different roles
  535. through the same membership. Membership is conceptually a base role in itself. Having an integrated
  536. T
  537. representation of the participation of a single actor is very valuable in supporting efficient communication
  538. and collaboration and supports pro-social investment in the actor’s reputation. Separating this from token
  539. holdings is valuable, as it allows for some type of participation to be possible without tokens, for example,
  540. 6.2
  541. DR
  542. AF
  543. as a means for actors to earn their first tokens
  544. Member, Profile and Registry
  545. A member is an actor who is registered in the membership registry and is defined as follows:
  546. 11
  547. Member
  548. - ID: Unique integer identifier.
  549. - Key: Public key. This is the key used to authenticate transactions as a member.
  550. - Handle: String used as human readable identifier (UTF-8).
  551. - Avatar: Storage identifier for avatar image (see section 11).
  552. - Description: String of capped length (UTF-8).
  553. - Added: Date and time when the membership was first established .
  554. - Entry: If membership was established through screening (see section 10), the this is set to ID
  555. of screening authority which created membership. If it was established through payment (see
  556. T
  557. section 6.3), then this is the paid term ID of the terms. Otherwise, its blank.
  558. - BRAQs Instances: Set of BRAQ instances for all base member actions (see section 4.4.2)
  559. DR
  560. AF
  561. - Suspended: Whether member is suspended.
  562. - Subscription: If at least one subscription has been entered, then this is the date and time of
  563. that event and the corresponding subscription term ID (see section 6.4). Otherwise its blank.
  564. The membership registry is simply a mapping that associates the identifier (ID) of a member with the
  565. corresponding profile. Lastly, there is also a set of BRAQ quotas, called the default membership quotas, used
  566. for all base membership BRAQ instances with indirect proxy quotas.
  567. The suspension field only impacts a member’s capacity to act through their base membership capacities;
  568. any action derived from other roles is unaffected. Also, a member may be suspended even if this field is not
  569. set (see section 10.4).
  570. A membership may be established for free, as explained in section 10, or it may be paid for a one time
  571. cost of burning a given amount of tokens. As a result of free entry, a given key may be associated with
  572. a membership but no account. The converse is also possible by definition. Once a membership has been
  573. established, it is permanent. For a given key, there may both a corresponding account and membership, or
  574. either one exclusively. While an actor may find it practical to identify with the same key in both capacities,
  575. the system cannot, and does not, enforce this.
  576. 6.3
  577. Paid Membership
  578. Paid membership terms represent a set of conditions for a prospective membership, through payment, on
  579. the platform, and is defined as
  580. 12
  581. Paid Membership Terms
  582. - ID: Unique integer identifier known as term ID.
  583. - Fee: Quantity of native token that must be provably burned.
  584. - Proxy Quota: Initial quota for membership.
  585. - Text: String of capped length (UTF-8) describing the human readable conditions to be agreed
  586. upon.
  587. The platform has a set of terms, called the active paid membership terms, which are currently in place
  588. for anyone seeking paid membership. It is updated through a council proposal. Any new terms introduced
  589. by the council must have an ID greater than the prior active terms; the initially active terms have an ID of
  590. 0. The full history of such terms that were once active is kept in a list known as the paid membership terms
  591. T
  592. record, which maps the term ID to the corresponding terms.
  593. A new actor may join as a member at any time through a request, which will burn the required fee from
  594. their account, so long as the platform is accepting members. This is gated by a platform variable referred
  595. 6.4
  596. DR
  597. AF
  598. to as the platform membership gate and can be changed through a proposal.
  599. Subscription
  600. Subscription terms represent a set of conditions for a prospective subscriber on the platform and are defined
  601. by the following:
  602. Subscription
  603. - ID: Unique integer identifier.
  604. - Fee: Quantity of native token that must be provably burned.
  605. - Duration: Number of blocks for which the subscription is valid.
  606. - Proxy Quota Delta: Set of proxy quotas added to the base level quotas to expand quotas.
  607. - Text: String of capped length (UTF-8) describing the human readable conditions to be agreed
  608. upon.
  609. A member with a subscription that is active, that is, the current block height is lesser than the sum of
  610. the subscription entry time and duration is referred to as a subscriber in this period.
  611. Similar to that of paid membership and terms, there is an analogues concept of active terms, terms
  612. record, and a gate.
  613. While members can establish subscriptions at any time, the time line is divided into subscription periods.
  614. In each period, a cumulative count of the total amount of fees burned for subscriptions is maintained. At
  615. the end of each period, payouts to relevant parties such as publishers, for example, are based on these final
  616. tallies.
  617. 13
  618. 7
  619. Roles, Staking and Slashing
  620. A role is a membership status having a fixed number of varieties, which gives access to a range of different
  621. rights and correspondingly confers a range of responsibilities. A given member may occupy multiple roles
  622. simultaneously.
  623. An actor may be required to lock up a certain amount of native tokens for some time under certain
  624. conditions, and this is referred to as staking. Typically, this is in the context of participating in some role
  625. or performing some action. In some roles, it is possible to raise or lower the staked balance on an ongoing
  626. basis within context-specific limits. There will often be a time before a change in the staked amount of
  627. tokens is counted toward the actual total staked balance. For increases, this is known as bonding period and
  628. for decreases unbonding period. If a stake reduction leads to the actual staked balance dipping below the
  629. minimum required for a given role at that time, then a full stake balance reduction is automatically initiated,
  630. and no increases can be initiated until the unbonding period is over. Tokens that are in one of these two
  631. periods are referred to as in flight. Tokens staked or in flight cannot be reused to stake in another context
  632. T
  633. at the same time.
  634. Under certain scenarios, it may be possible for a member to lose all or a part of their stake; this is referred
  635. 8
  636. DR
  637. AF
  638. to as slashing.
  639. Rewards
  640. All staking is rewarded in tokens paid out directly to the member account and, if no account exists, then the
  641. membership key will be used to credit an account with the same key. These payouts will come at the end
  642. of some corresponding time interval and are comprised of two components. The first component, known as
  643. the compensation payoff, is of the form xrT , where x is the staked quantity, r is a global nominal per block
  644. interest rate, and T is the number of blocks in the given period. If the staked quantity has varied over the
  645. period, then x will represent the average time weighted quantity. The second component, referred to as the
  646. earned payoff, is related to the particular activity or role that was undertaken in the given period. Hence,
  647. the total reward to a given stake in a given period may be written as
  648. P
  649. x i ∆i T
  650. r +C
  651. T
  652. where xi is the quantity staked in the i-th sub period, which itself lasted ∆i blocks, and C is the earned
  653. i
  654. payoff.
  655. 9
  656. 9.1
  657. 9.1.1
  658. Governance
  659. Council
  660. Terms
  661. The governance process is divided into a sequence of periods known as terms, and the first term is known as
  662. the bootstrap term. Each term, with the exception of the bootstrap term, has a corresponding council, which
  663. is a set of staked members responsible for voting over submitted proposals. Proposals are bids to execute
  664. given operations on the platform state in order to serve some contemplated end.
  665. 14
  666. 9.1.2
  667. Elections
  668. The council for a given term is established through a council election, where all members have the opportunity
  669. to place weighted backing behind prospective councilors who announce their bid for council membership and
  670. put up their own corresponding stake. The election is conducted toward the end of a term, and current
  671. council members are expected to carry out their responsibility of dispatching proposals throughout their
  672. term. The number of council positions in the next term is always set to a given number in the preceding
  673. term referred to as the council size. This may be altered through a proposal. A new number goes into effect
  674. at the start of the next term.
  675. The election has four stages.
  676. - Announcements stage: Members get to announce their candidacy for the council. They need to put
  677. a minimal amount of stake to be able to do this, which is known as the council staking limit. This limit
  678. may be altered through a proposal, and the new limit may come into effect at the start of the next
  679. term. When not in the bootstrap term, there may already be existing council members who are also
  680. T
  681. welcome to announce for the next term, which denotes extending candidacy. A council member may
  682. in this case reuse their existing stake, which is referred to as transferring council stake. In this case,
  683. they may have to adjust their staking amount to satisfy a staking limit that may have been altered.
  684. DR
  685. AF
  686. There is an upper limit to the number of candidates that may be voted upon and is termed the council
  687. candidacy limit. This limit may be altered through a proposal, and the new limit may come into effect
  688. at the start of the next term. If there are more candidates satisfying the staking limit than this limit,
  689. then candidates are ranked based on the staked amount. The set of candidates who actually end up
  690. being eligible after this constraint is applied and termed candidate pool.
  691. - Voting stage: All members, including current and prospective council members, back candidates for
  692. the next term. Backing refers to staking in support of the candidacy of a member in the candidate
  693. pool. Each backing is a sealed commitment to a particular candidate, where the seal is simply salted
  694. hashing the candidate identifier. A member may reuse tokens already staked behind an existing council
  695. member to a member of the candidate pool, which is referred to as transferring backing stake.
  696. - Reveal stage: All members who backed candidates must submit their salts to reveal the candidate in
  697. each of their backings. At the end of this period, all backings are tallied for all members in the pool,
  698. and all backings without a corresponding revelation are ignored. Regarding considering the council
  699. members during tallying, the candidate pool members are ranked in terms of the total amount of stakes
  700. across all revealed backings in their favour. All those outside the council size are discarded and, if the
  701. council size is not filled, then one can re-enter the announcement stage.
  702. - Grace stage: All stake introduced in the given term backing a losing candidate or not revealed,
  703. is immediately unstaked. This is done so that all new stake is able to exit the consequences of an
  704. unfavourable council. At the end of this period, a new term begins with a new council. This is also is
  705. the start of the unbonding period for all stake that does not continue in the next term.
  706. 15
  707. 9.1.3
  708. Rewards
  709. Voters do receive an earned payoff; however, council members receive a payoff proportional to the rate of
  710. participation in processing proposals, which is is of the form pi uCM , where pi is the participation rate, i.e.,
  711. rate of non-abstention (and thus revealed) votes over all votes of the i-th council member, and uCM is a base
  712. reward across all council members for the given period.
  713. 9.2
  714. 9.2.1
  715. Proposals
  716. Types
  717. At any given time, there exists a finite set of different proposal types. Each type is a value for each of the
  718. following properties that apply to all proposals of the given type.
  719. - Quorum: The percentage of the council participants who must vote affirmatively in order for the
  720. proposal to pass.
  721. T
  722. - Threshold: The minimum percentage of quorum that must vote for a given alternative for it to pass.
  723. - Constitutionality: The number of council periods in a row that must confirm the proposal for it to
  724. DR
  725. AF
  726. pass.
  727. A proposal type takes the form of one among three different types of propositions. The binary proposition
  728. is a simple pass or reject, the multiple choice proposition require selecting one among at least two different
  729. affirmative alternatives or rejection and, lastly, the ranked choice proposition requires providing a total
  730. ranking of a finite set of alternatives or rejection.
  731. 9.2.2
  732. Life cycle
  733. A proposal, of a given type, is first created by a member referred to as the proposal sponsor. The sponsor
  734. has to back the proposal with a given amount of stake. This amount may be altered through a proposal,
  735. and the new amount goes into effect at the start of the next term. Once a proposal has been created, the
  736. council members can start submitting sealed votes on the proposition in what is known as the voting stage.
  737. The sealed vote can be one among
  738. - Abstention: Signals presence, but unwillingness to cast judgment on substance of vote.
  739. - Reject: Against proposal.
  740. - Affirm: Pass an alternative or a ranking for binary, multiple-choice, and ranked-choice propositions,
  741. respectively.
  742. - Slash: Against the proposal, and slash proposal stake.
  743. This stage ends on the earliest of the following events
  744. (a) All council members have submitted sealed votes.
  745. (b) Time since proposal creation has exceeded a designated platform parameter. This amount may be
  746. altered through a proposal, and the new amount goes into effect at the start of the next term.
  747. 16
  748. (c) End of the given term, the point at which the proposal is automatically rejected by the council.
  749. The next stage allows the council members to submit revelations for their prior sealed votes and is referred
  750. to as the revelation stage. At the end of this stage, the tallying commences, which works as follows.
  751. If all revealed votes are slashes, then the proposal is rejected and the proposal stake slashed. To clear
  752. the quorum requirement, the percentage of council members with revealed votes must be no less than the
  753. quorum value for the given proposal type. To clear the threshold requirement, the percentage of council
  754. members voting in favour of the proposition must be no less than the threshold. For multiple and rankedchoice propositions, this is interpreted to mean the number of votes in favour of the most popular choice or
  755. single ranking, respectively.
  756. When a proposal passes, it needs to immediately be put into effect; however, many proposal types have
  757. some applicability pre-condition that must be satisfied for it to be valid. If this does not hold at this time,
  758. then the proposal is simply discarded. This can occur in scenarios where the state of the platform changes
  759. in a way not foreseen by the initial proposal sponsor or council.
  760. T
  761. In all scenarios given above, an archived record of how a proposal was processed will be left for future
  762. inspection.
  763. Working Groups
  764. DR
  765. AF
  766. 9.3
  767. All non-validator service-provider roles on the platform are organized into domain specific groups termed
  768. working groups, which comprise the following.
  769. 1. Membership screening: Grant membership status to members while trying to avoid Sybil.
  770. 2. Membership curation: Monitor membership base for abuse and Sybil attacks.
  771. 3. Content: Curates and manages the availability and integrity of content in the content directory.
  772. 4. Storage and distribution: Stores and distributes static data to consumers on demand.
  773. 5. Live streaming (in future draft): Distributes dynamic video data to consumers.
  774. 6. Discovery: Provides standard discovery services over the content directory to consumers, i.e., search
  775. and recommendations.
  776. 7. Software development: Develops and deploys all software assets of the platform, including consensus
  777. code and user facing applications.
  778. 8. Content finance: Curates content finance market and adjudicates project disputes.
  779. 9. Advertising: Polices the advertising market on the platform.
  780. 10. Communications (in future draft): Administrates the on-chain forums, messaging channel governance, and user support inquires.
  781. 17
  782. 9.3.1
  783. Leads and workers
  784. Each group has two distinct types of roles, namely the group lead and the worker. Leads are elected by
  785. the council through the proposal system and are responsible for populating and managing other roles in the
  786. given group as well policing the conduct of group workers. Leads can also be replaced or evicted and, if the
  787. latter, or if there is no lead to begin with, then no group workers can perform any platform-level actions
  788. until a new leader is installed. The particular rights and privilege of a worker is entirely dependant on the
  789. group in question.
  790. Each group pays out a reward to all group members at a given interval referred to as the group payout
  791. period, which is a platform parameter distinct for each group. This may be altered through a proposal, and
  792. the new value goes into effect at the start of the next period.
  793. 9.3.2
  794. Installing, replacing, and evicting leads
  795. There are two scenarios under which a new group lead may be introduced in a given group: in the case
  796. T
  797. where there is no existing lead, which is only the case while bootstrapping, and is referred to as installation;
  798. when an existing lead is leaving their position by their own initiation or alternatively by initiative from the
  799. council, and a new one is to be introduced. These are referred to as replacement and eviction, respectively.
  800. DR
  801. AF
  802. In all cases, candidates for a group lead role come from a list on the platform for the given group, referred
  803. to as the group lead candidate list. Members can enter the list by staking the amount required to hold the
  804. group lead position for the given group. Each list is a fixed size and, if the number of potential candidates
  805. who have staked is greater, then inclusion is determined by how much has been staked beyond the limit,
  806. although the actual staked amount when introduced a lead is always the staking limit.
  807. 10
  808. 10.1
  809. Membership Screening and Curation
  810. Overview
  811. As mentioned before, for example, in section 6, it should be possible to onboard users who do not hold any
  812. tokens. This activity, referred to as screening, allows the platform to accommodate new users who wish
  813. to try the platform within certain constraints. However, the combination of no robust identity system and
  814. allowing users to consume resources without paying on the margin creates its own set of new problems.
  815. These resources need not only be in the form of tangibles such as compute and storage, but can also be
  816. things like peer member attention. Not only does this result in wasteful overutilisation but, perhaps, more
  817. importantly, it allows platform participants to shape their own payouts at a low cost, since resource use is
  818. often tied to payouts. For example, viewing content will divert a larger share of payout to the publisher.
  819. The Joystream protocol also suffers from these ills in principle, at least under a certain set of policy choices.
  820. There is no final solution to this without dealing with the fundamental identity and pricing preconditions.
  821. None the less, it is critical to equip the platform with a baseline capacity to engage in the presumed catand-mouse dynamic with such abuse to reduce the feasibility and cost of attacks.
  822. This is achieved by two measures: first, there is a capacity to block access to the platform in various
  823. ways. This activity is termed suspending and specifically prevents the relevant actor from being able to
  824. participate in the platform through base membership actions. Second, when anyone is onboarded through
  825. 18
  826. screening, the corresponding platform actor who onboarded them is recorded and can be punished for a long
  827. time in future, with a suitable bonding period if the abuse is uncovered.
  828. 10.2
  829. Working groups
  830. This work is parceled out into two complementary working groups, the screening and curation working
  831. groups. Both groups allow all members to engage in the same set of group activities, except for the lead,
  832. which is also involved in normal group lead activity.5
  833. 10.3
  834. Screening
  835. Participants in the screening working group can engage in the screening process and are in that capacity
  836. referred to as a screening authority.
  837. The precise steps involved in screening, which is an offchain process, are entirely exogenous to the protocol.
  838. The set of actual policies and corresponding tools in production at any given time is expected to be the
  839. mechanisms that can be employed comprise the following:
  840. DR
  841. AF
  842. (a) Email or social media confirmation.
  843. T
  844. result of an ongoing coordination, based on policy constraints from the council and group lead. Obvious
  845. (b) CAPTCHA, or other labeling, or perceptual tasks.
  846. (c) Onboarding delays.
  847. (d) Manual human confirmation.
  848. As part of being screened, a prospective member must accept a set of terms referred to as the screening
  849. terms and defined as
  850. Screening terms
  851. - ID: Unique integer identifier.
  852. - Proxy Quota: Initial quota for membership.
  853. - Text: String of capped length (UTF-8) describing the human readable conditions which are
  854. being agreed upon.
  855. The terms to be used at any given time are known as the active screening terms and can be changed
  856. through the proposal system.
  857. A new member can be added through screening authority by presenting a signature of the current active
  858. terms (or similar) using a key that can also be used as a basis for the membership. When this happens, the
  859. ID of the authority is also included in the membership (see section 6.2).
  860. 5 In
  861. principle it is probably advisable to keep the screening group small, even perhaps to a single actor at any given time,
  862. in order to keep the set of stakeholders in this capacity limited. This also makes a longer unbonding and staking period more
  863. economical.
  864. 19
  865. 10.4
  866. Suspension
  867. The organization and principles of this working group are identical to the screening working group. There
  868. are three distinct forms of suspension that can be initiated, namely
  869. - Individual: A specific member can be suspended by setting the appropriate membership field.
  870. - Group: A proposal can be submitted allowing for the simultaneous suspension of all members who
  871. have been added through screening from a given screening authority within a given window of time in
  872. the past.
  873. - Lock down: A proposal can be submitted allowing for simultaneous suspension of all members.
  874. 10.5
  875. Rewards
  876. Data storage and distribution
  877. 11.1
  878. Overview
  879. DR
  880. AF
  881. 11
  882. T
  883. All working group participants have some given group-based periodic payoff set by the council.
  884. Reliably storing and distributing off-chain static data at scale is one of the primary requirements of the
  885. platform. This includes data such as media content, metadata, applications and static assets, and private
  886. (encrypted) member data such as preferences and statistics. Specifically, this subsystem should satisfy a
  887. range of objectives
  888. - Consumption: Members can
  889. (a) upload content, respecting certain platform quota limits, for free and expect permanence and
  890. distribution.
  891. (b) securely download data, respecting certain platform quota limits, for free.
  892. (c) fully utilize a system with communication and resource constraints of a browser.
  893. - Paying: Quota restrictions can be augmented as a result of paying (e.g. through subscription) or
  894. discretionary changes made by platform governance.
  895. - Fault tolerance: Storage has some level of fault tolerance for all content, which ensures that single
  896. actor faults do not lead to permanent data loss. This replication should economize on cost and be
  897. sensitive to platform policy regarding the desired rate of tolerance.
  898. - Dynamic: The platform should dynamically be able to be and remain effective at distributing content
  899. in concert with changes in total volume of downstream demand and where this demand is located.
  900. - Privacy: View counts and quota limits are maintained without leaving a permanent public history of
  901. what end user viewed what and sharing viewing activity with as few counterparties as possible.
  902. 20
  903. - Ad Awareness: It may be desirable to interleave media distribution with a dynamic advertising
  904. system and, in order to support this, the infrastructure must know when to inject what ad, to whom,
  905. and how long to block until normal distribution is resumed.
  906. - Low Bar: Barrier to entry for aspiring service providers is not too high, for example, in the requirement
  907. of lots of hardware or stake.
  908. The key problem in organizing this part of the platform is correctly enforcing rewards and punishments
  909. on the infrastructure providers. This requires that one accurately determines whether they are behaving
  910. correctly. At the core of this assessment lies the problem of how to adjudicate disputes over the timeliness
  911. and integrity of response to queries. It is fundamentally not possible to furnish direct purely cryptographic
  912. proofs about such claims; hence, the fallback of most alternatives is to construct mechanisms that provide
  913. game theoretic assurances of honest and reliable conduct. These alternatives most often attempt to be
  914. open commodity markets, where buyers and sellers have temporary relationships. Here, a much simpler
  915. approach is utilized, where most good conduct is expected based on risk of governance-based sanctions on
  916. is assumed to be reliable due to being a long-term player.
  917. Working Group
  918. DR
  919. AF
  920. 11.2
  921. T
  922. deposited bonds, and losing reputational capital. Honesty of the platform, and thus its governance outcomes,
  923. The working group is made up of the following roles
  924. - Lead: Has the normal group-lead responsibilities, but also performs two additional coordinating functions, namely
  925. (a) Produces policy for how different data should be distributed at any given time.
  926. (b) Receives and processes errors about misconduct or unavailability among group members.
  927. - Storage: Stores a copy of some subset of data in the data directory and replicates to peers and
  928. distributors upon request.
  929. - Distributor: Distributes data in the data directory on demand to members.
  930. 11.3
  931. Storage providers
  932. A storage provider is member of a group of providers termed storage tranche group who share the same
  933. participation terms. A tranche is defined as follows:
  934. 21
  935. Storage provider Tranche
  936. - ID: Unique integer identifier.
  937. - Capacity: The number of bytes of storage capacity required.
  938. - Out speed: The number of Mbps required.
  939. - Stake: The amount of stake required.
  940. - Duration: The number of block service to be provided from the initiation block.
  941. - Fixed Reward: Quantity of native token earned per unit of time.
  942. - Variable Reward: Quantity of native tokens earned per unit of date stored.
  943. - Slots: Total number of roles available in this tranche.
  944. T
  945. - Terms: String of capped length (UTF-8) describing the human readable conditions to be agreed
  946. upon.
  947. DR
  948. AF
  949. - Active: Whether tranche is actually possible to use, that is, assign new members.
  950. All these are kept in a mapping known as the tranche registry, which maps tranche ID to the corresponding
  951. tranche. Even when a tranche is no longer active, or will be used in the future, it continues to be a part of
  952. the registry.
  953. The participation of a member in the role as a storage provider is represented by a tranche membership
  954. and is defined as follows:
  955. Tranche membership
  956. - Member: Membership ID.
  957. - Tranche: Tranche profile ID.
  958. - Started: Block height where role started.
  959. - Availability: Amount of bytes still available.
  960. - Active: The block at which this provider is to be considered active.
  961. - Paused: Whether this role is currently paused.
  962. Such profiles live in a mapping from the ID to the profile termed the storage providers. A member is only
  963. considered a provider when the corresponding profile is registered in this map, and this happens through the
  964. group lead. The active status of a membership is meant to afford some time between when the provider has
  965. entered the role and when there is a full obligation to provide service. The pausedness of a membership is
  966. meant to allow discretionary pause in inbound storage requests due to extraordinary circumstances and can
  967. be invoked by the member or lead directly.
  968. 22
  969. Note that the same member may participate as a storage provider multiple times and under different
  970. tranches.
  971. 11.4
  972. Distributors
  973. Distributors are organized in a very similar way to storage providers, with analogous concepts such as
  974. distributor tranche group, profile, registry and membership, with suitable minor alterations. In particular,
  975. tranches will also include information about geographically bound latency guarantees and the number of
  976. simultaneous upstream connections.
  977. 11.5
  978. Data directory
  979. The platform maintains state about the available data, and how it is distributed, in the data directory. All
  980. data objects stored correspond to one among a finite set of data object types. Each type is meant to capture
  981. T
  982. the following storage and distribution requirements for some broader family of objects:
  983. - Infrastructure requirements: By allowing a range of guarantees about permanence and performance, which better aligns with the underlying requirements of different data objects, one can allow
  984. DR
  985. AF
  986. better resource utilization.
  987. - Access policy: Some objects may only be accessible to a given member for certain periods of time,
  988. if at all. The obvious example will be data objects behind paywalls.
  989. - Accounting procedures: Some objects may require some kind of accounting or cleanup as a result
  990. of accessing the data. This can, for example, be used to record reliable access statistics for media
  991. content, i.e., view count.
  992. The first requirement is about reducing cost while the latter two about making the same infrastructure
  993. parametric and thus reusable for a wide range of purposes. A data object type is specifically designed as
  994. follows:
  995. Data object type
  996. - ID: Unique integer identifier.
  997. - Description: Human readable description.
  998. - Size limit: When set, represents the maximum number of bytes.
  999. - Replication factor: Number of copies for data objects of this type that need to exist in the
  1000. storage system at any time. The simplest interpretation for this is the minimum number of
  1001. storage providers that must replicate the data object.
  1002. - Storage tranches: Set of tranche IDs that can be used with this data type. If empty, then
  1003. any tranche can be used.
  1004. - Active: Whether objects of this type can be added at this time.
  1005. 23
  1006. All available types are kept in mapping termed the data object type registry, which maps the ID to such a
  1007. type. Admissible storage tranches are in part kept on the platform to allow automatic assignment of storage
  1008. providers to any new data object of a given type. For the same reason, there is no commitment to the
  1009. distributor tranche because distribution requirements will often depend on internal details about the data
  1010. object itself, which are hard to fully describe.For example, it can be the case where whenever a particular
  1011. publisher uploads a media item, there are substantial inbound download requests from a corresponding area.
  1012. This type of policy rule is better left to discretion to setup rather than an automatic consensus rule.
  1013. Each data object is defined as follows:
  1014. Data Object
  1015. - CID: A content identifier that allows secure authentication of the data under some implicit
  1016. chunking schema.
  1017. - Size: Number of bytes occupied by data.
  1018. DR
  1019. AF
  1020. - Added: Date and time for original upload event.
  1021. T
  1022. - Type: Data type ID.
  1023. - Origin: ID of member who uploaded the data.
  1024. - Liaison: ID of storage provider that accepted the initial upload.
  1025. - Liaison judgement: One among pending, rejected, and accepted.
  1026. All records are kept in the data object registry, which is a mapping from the CID to the corresponding
  1027. record. The fact that a storage provider is storing a data object is represented by a data object storage
  1028. relationship, which is defined as follows:
  1029. Data object storage relationship
  1030. - ID: Unique integer identifier.
  1031. - CID: CID of data object.
  1032. - Storage: ID of storage provider which should store object.
  1033. - Ready: Whether the service relationship is ready to be honored by the provider.
  1034. Such relationships are kept in the storage relationship registry, which maps the ID to the relationship.
  1035. Analogous concepts for distribution that are referred to as data object distribution relationship and distribution relationship registry also exist.
  1036. Lastly, a member downloading a data object is represented by a download session, which is defined as
  1037. follows:
  1038. 24
  1039. Download session
  1040. - CID: ID for content.
  1041. - Consumer: ID for member downloading.
  1042. - Distributor: ID for distributor that distributes the content.
  1043. - Initiated: Date and time when the session was initiated.
  1044. - State: Either started or ended.
  1045. - Transmitted: Amount of bytes of data actually downloaded.
  1046. Such sessions are kept in the download session registry, which maps the ID to the session. Please see the
  1047. discussion (section 18) on how to address obvious scale and privacy problems introduced by sessions and the
  1048. 11.6
  1049. T
  1050. registry.
  1051. Uploading
  1052. DR
  1053. AF
  1054. A normal uploading flow is as follows 6 :
  1055. 1. The user issues a transaction to create a new data object record by providing a CID for the underlying
  1056. payload as well as information about its size and type ID. The transaction is only valid if
  1057. (a) the CID is not already in the data registry.
  1058. (b) the size respects data type size limit.
  1059. (c) data type is active.
  1060. (d) sufficient storage capacity is available among active, non-paused, storage providers within the set
  1061. of tranches available for data type.
  1062. (e) uploader has no other data object records with pending liason judgment.
  1063. If so, this will result in the creation of a data object record, where the liason and storage object
  1064. relationships are automatically assigned. All the latter have an initial status of not being ready. The
  1065. liason judgment is set to pending. If the record remains pending over some time limit, then the record
  1066. goes away, and the lead is needed to inspect any received error reports.
  1067. 2. The user connects to the liason and requests to upload the data by referencing the data object record.
  1068. The storage provider can validate the request by reading the platform state and can only then proceed
  1069. to accept the upload.
  1070. 3. The storage provider will check
  1071. (a) the payload matches the CID,
  1072. (b) has the right size, and
  1073. (c) passes an upload filter7
  1074. 6 This
  1075. is a highly informal description which will be fleshed out in future drafts.
  1076. 7 TBD.
  1077. 25
  1078. If either fails, the judgment will be set to rejected for the given reason. If all pass, the judgement will
  1079. be set to accepted, and the corresponding storage relationship will be set to ready.
  1080. 4. The liason must accept incoming replication attempts from all other providers with a storage relationship with the given record. As they receive the payload, each has a responsibility to alter the readiness
  1081. of their storage relationship. Any relationship that is still not ready after some defined period of time
  1082. from the time the record has been added is considered a failure. At this point, the lead must inspect
  1083. any possible reported errors and adjudicate.
  1084. 5. When the time limit for replication by all storage providers has been exceeded, the lead creates distribution relationships for the record based on local policy.
  1085. 6. The distributors corresponding to the new relationships can connect to the storage providers that have
  1086. corresponding storage relationships with ready status to acquire a copy of the payload.
  1087. Downloading
  1088. T
  1089. 11.7
  1090. A normal downloading flow is as follows 8 :
  1091. DR
  1092. AF
  1093. 1. The downloader issues a transaction to create a download session by providing the relevant CID. The
  1094. transaction is accepted once the following holds:
  1095. (a) the CID corresponds to a data object record
  1096. (b) the data object record has at least one distributor relationship that is ready
  1097. (c) the access policy of the data type accepts the request
  1098. If so, then a session is added to the session registry, which is in the started state and where the
  1099. distributor has been chosen from the available ready set.
  1100. 2. The downloader connects to a host corresponding to the assigned distributor and authenticates and
  1101. finally provides a verifiable reference to the new session.
  1102. 3. The distributor sends verifiable (based on Authority Key) data chunks in response to requests from
  1103. the downloader in a tit-for-tat exchange. The downloader sends to the distributor a signature over
  1104. the claim that a certain total amount of data has been transmitted over the lifetime of the session,
  1105. analogous to payment channels [10]. To avoid latency, there should be some amount of pipelinining.
  1106. 4. The exchange ends when either all data has been sent or when the downloader has terminated the
  1107. exchange. At this point, the distributor will submit a new transactions with the most recent signed
  1108. consumption statement from the downloader. This transaction will settle both the actual consumed
  1109. data in the session and the state of the session.
  1110. 5. Any data type specific accounting policy is executed with reference to the session.
  1111. 8 This
  1112. is a highly informal description which will be fleshed out in future drafts.
  1113. 26
  1114. 11.8
  1115. Entry, exit, and distribution policy updates
  1116. There are a number of key infrastructure dynamics, such as entry and exit of actors into the roles as
  1117. distributors or storage providers, and also updates on what is being assigned to what data. These may be
  1118. initiated and coordinated through off-chain messaging protocols. An honest conduct is expected purely on
  1119. governance sanctions. This will be described in further detail in the future.
  1120. 11.9
  1121. Policing and data removal
  1122. The storage and distribution infrastructure is really a utility for the rest of the platform, hence the removal
  1123. of data from this infrastructure, for any reason, is under the control of the working group which has control
  1124. over the use case to which the data corresponds.
  1125. 11.10
  1126. Rewards
  1127. T
  1128. All payouts take place at a given group-specific payout interval. The group lead is paid a given amount of
  1129. tokens regardless of what has occurred. Storage providers and distributors both have a fixed and variable
  1130. payout component, where the latter is based on the actual stored or distributed data quantities, and the
  1131. DR
  1132. AF
  1133. rates are captured in the corresponding tranche profiles. The actual variable base quantities are maintained
  1134. through the uploading assignment process and data type-specific accounting policies, respectively.
  1135. 12
  1136. Content directory
  1137. 12.1
  1138. Overview
  1139. The content directory contains information about the media content available on the platform. More importantly, it does not contain the primary media itself, which is stored in a separate off-chain infrastructure
  1140. described in the section on storage and distribution (section 11).
  1141. 12.2
  1142. Working group
  1143. The working group comprises the lead and the member. Members are responsible for executing the following
  1144. functions
  1145. - Curation: Ensuring that the underlying content media and metadata correspond to each other, e.g.,
  1146. in that they display assets are correct or content is in the correct category, etc.
  1147. - Policing: Adjudicating disputes around the availability, ownership, and attribution of content.
  1148. - Filtering: Maintaining and developing the filtering technology in place when publishing to the directory.
  1149. - Verification: Granting privileged status to publishers and content as verified and canonical, which
  1150. helps in discovery and resolves disputes over the publisher namespace.
  1151. 27
  1152. 12.3
  1153. Publisher
  1154. A publisher is a member who is allowed to publish content in the content directory and is defined as follows:
  1155. Publisher
  1156. - Name: This is separate from membership name and is its own namespace.
  1157. - Description: A description of the publisher.
  1158. - Brand artifacts: Data directory CIDs for a set of off-chain artifacts that make up the profile
  1159. brand identity.
  1160. - Verification status: Whether the implied identity of the publisher profile matches the actor
  1161. 12.4
  1162. T
  1163. who is in control of the membership.
  1164. Content
  1165. DR
  1166. AF
  1167. There is a base set of properties for all content on the platform, which includes the following:
  1168. - Category: The type of content.
  1169. - Payload: Data directory identifiers for media and metadata.
  1170. - Owner: A publisher or content project planner (see section 15) who has control over the content and
  1171. rights to value.
  1172. - Monetization policy: How end users must pay to access content, among which are being free (with
  1173. or without advertising), transactional, or subscriber access (only subscribers have access).
  1174. - Dispute status: Whether some dispute is currently ongoing. This has implications for how end users
  1175. should engage with the content.
  1176. There are a fixed set of primary content categories that are supported at any given time. Each category
  1177. defines a particular schema for how to define key properties, including
  1178. - Payload format: How to organize the media payload.
  1179. - Rendering: Metadata about how to play back or render media.
  1180. - Accessibility resources: Things that assist a variety of users in consuming the content, such as
  1181. subtitles or translation metadata, dubbing information, etc.
  1182. - Attribution: Defines who did what in the process of producing the content.
  1183. Content will also have associated social information around engagement, such as view/access rates and
  1184. counts, likes, and a comment feed.
  1185. 28
  1186. 12.5
  1187. Disputes
  1188. Any member can submit a dispute about any published content, and these disputes are processed by the
  1189. working group. There will be a range of different dispute forms, some with the goal of entirely removing
  1190. content while others with changing attribution or ownership information and, as a result, redirect revenue
  1191. streams.
  1192. 12.6
  1193. Rewards
  1194. All group members are paid fixed amounts per unit of time.
  1195. 13
  1196. Discovery
  1197. 13.1
  1198. Overview
  1199. T
  1200. In order for end users to effectively discover relevant content in the content directory, access to the directory
  1201. is required, and the ability to execute effective processing heuristics across this data needs to be set promptly.
  1202. In order to alleviate the resulting processing and bandwidth costs, this will impose there is a designated set
  1203. 13.2
  1204. DR
  1205. AF
  1206. of discover nodes that provides these services.
  1207. Working group
  1208. The working group is composed of members that run nodes running a discovery provider service, as described
  1209. in the next section.
  1210. 13.3
  1211. Services
  1212. There are three types of discover services that are offered by discovery provider nodes
  1213. - Search: Keyword and filter-based ranked lists of content.
  1214. - Browsing: Category and filter-based ranked lists of content.
  1215. - Recommendations: Content identifier-based ranked lists of content.
  1216. In all three cases, the response provided by a service provider includes the relevant content as well as
  1217. Merkle proofs, which allows the client to authenticate the integrity of the response. If required, one can extend
  1218. this to have automated slashing based on bad proofs sent to clients. There is no way to prove omission in this
  1219. scheme. There will not be a well-defined definition of what this may imply, as different discovery providers
  1220. are free to pursue their own ranking and discovery policy. Reasonable incentives for good behavior can be
  1221. generated by encouraging user clients to keep local statistics about the success rate of various providers or by
  1222. measuring user behavior, which will in turn drive more traffic to better providers. Likewise, the incentive to
  1223. generate more traffic can be generated by giving a provider the privilege of displaying in-place advertisement,
  1224. which is not hooked into the normal advertising ecosystem. The inclusion of minimal telemetry feedback to
  1225. providers can also help them guide the development of their own discovery policies.
  1226. 29
  1227. 13.4
  1228. Rewards
  1229. Beyond the incentive described in the prior section, all providers are given a fixed token reward per unit of
  1230. time.
  1231. 14
  1232. Software development
  1233. 14.1
  1234. Overview
  1235. Software development needs to be understood broadly, encompassing all activities surrounding research,
  1236. production and testing of standards (e.g. analogous to BIPs or EIPs), protocols, algorithms, source code,
  1237. binaries and other digital software assets, as well as deploying such outputs into production environments.
  1238. Three aspects of this activity are of importance to the platform.
  1239. Financing
  1240. T
  1241. 14.1.1
  1242. Many protocols suffer from the lack of an endogenous financing mechanism, and stateless protocols cannot
  1243. have them by definition. Even in many stateful protocols, key contributors end up either severly underfunded,
  1244. DR
  1245. AF
  1246. which is detrimental to quality and development progress, or relying on third-party revenue sources that do
  1247. not have incentives that are guided by the interests of all protocol stakeholders.
  1248. To address this, the platform has a dedicated working group of contributors who are rewarded for providing these sorts of services and are accountable to stakeholders through the governance process.
  1249. 14.1.2
  1250. Development
  1251. For a variety of reasons, most software development projects for open stateful protocols end up with an
  1252. equilibrum where the development process is organized around a canonical collaborative state. By collaborative state, we mean some sort of code base and social collaboration metadata about that code base.
  1253. For example, the state may often be a Git repository, and the collaboration metadata may be repository
  1254. hosting service of some kind, or it can be a curated mailing list of patches and discussion. Ultimately, some
  1255. social consensus process emerges for how changes to this state is made and, almost invariably, this process
  1256. becomes a source of market power, its integrity becoming a security risk, and is not formally accountable to
  1257. protocol stakeholders. Socially desirable changes may be rejected or adopted too slowly, and changes that
  1258. are undesirable may be adopted. While fork based exit is in principle an option, it is also expensive. This
  1259. results in the following specific requirements:
  1260. - Accountable canonicity
  1261. The platform provides the means by which everyone securely resolves the same collaborative state at
  1262. all times.
  1263. - Open contributions
  1264. Any member should be able to submit a proposal for changes.
  1265. - Direct control
  1266. The governance process may directly mutate the state at any time.
  1267. 30
  1268. - Gated updating and moderation
  1269. Designated role(s) occupied by a dynamic actor set, subject to governance, have the right to accept
  1270. contributions or make changes on an ongoing basis.
  1271. - Immutable and secure updating history
  1272. An immutable history of all state changes. Even a Git repository only gives a history of states, but
  1273. is devoid of secure information about whether a given commit was introduced by someone who had
  1274. the right to do so. Merged commits are in this respect particularly sensitive, as this is typically the
  1275. way new changes make their way into producing source snapshots. Moreover, Git does not include the
  1276. broader collaborative state.
  1277. - Robust availability guarantees
  1278. The highest level of guarantee is required around the actual availability of state.
  1279. Given this set of requirements, the platform maintains a set of on-chain Git repositories, which include
  1280. T
  1281. familiar functionality, such-a-pull requests, merging, issue tracking, permissions, and publishing releases and
  1282. test/CI results. Critical changes such as merging are conducted in consensus using ATP.
  1283. Deployment
  1284. DR
  1285. AF
  1286. 14.1.3
  1287. Deployment is the process of converting a set of source assets into final production assets, like binaries, and
  1288. distributing these securely, and possibly automatically, to end users. This requires the following:
  1289. - Build authentication
  1290. Given a commitment to a set of source assets, there must be a reliable, reproducible, and secure way
  1291. for anyone to determine whether a particular set of production assets are the correct output of this
  1292. process.
  1293. - Secure updates
  1294. There must be secure way for users to acquire or run new versions of software binaries.
  1295. Given this set of requirements, there is a set of standards for defining and conducting deterministic builds.
  1296. Software updates occur directly from the platform state.
  1297. 14.2
  1298. Working group
  1299. There are two group types: lead and contributor. The lead is responsible for creating and assigning permissions on projects to contributors in order to help them perform write operations directly. While anyone can
  1300. in principle contribute through their effort to development, only contributors have a recurring reward for
  1301. their involvement. The working group also has its own messaging channel.
  1302. 14.3
  1303. Project
  1304. A project is the following set of items stored on chain:
  1305. 1. Git repository.
  1306. 31
  1307. 2. Permissions for who, in the working group, is allowed to make write operations, i.e., push and merge
  1308. into it.
  1309. 3. A set of open issues and pull requests with a corresponding discussion thread.
  1310. 4. A set of releases associated with tagged commits.
  1311. The normal write operations in Git repositories, such as initialization, pushing, merging, and tagging,
  1312. are fully secured by the platform itself by having the Git processing rules embedded in the consensus itself.
  1313. Opening issues and pull requests are open to any platform member, but only a working group member with
  1314. suitable permissions can actually moderate issues or merge requests.
  1315. 14.4
  1316. Artifacts, reproducible, and releases
  1317. An artifact is a file that is the result of some processing of the source material in a project repo commit. This
  1318. processing may involve processes such as building, linking, and packaging. There is a format to describe such
  1319. T
  1320. processes, and these will always yield fully deterministic outputs. These processes occur entirely off chain;
  1321. however, the determinism about the outputs is critical in order to facilitate reliable coordination around
  1322. the results, in particular around the validity of hash commitments of the artifacts. The most important
  1323. DR
  1324. AF
  1325. process is the building process, where this determinism provides reproducible builds. A release is a simple
  1326. publication of a set of artifacts corresponding to a tagged commit. This can only be done by the group lead
  1327. and, if the proposed hash commitments turn out to be fraudulent, then they can be challenged through a
  1328. proposal by anyone. If found to be a correct challenge, then the lead will face sanctions and the challenger
  1329. will get reward.
  1330. 14.5
  1331. Automated testing
  1332. There is a format for describing how to run tests off chain. The presence of tests’ metadata prevents pull
  1333. requests from going through unless the group lead signs on them as suitably passing. Just like in the release
  1334. process, such sign offs can be challenged.
  1335. 14.6
  1336. Deployment and upgradeability
  1337. There are two types of deployments on the platform. Light deployments simply involve updating the platform
  1338. state to reflect a new version of some application is available, whether it is backward compatible, and thus
  1339. optional, and how to retrieve the application itself.
  1340. The other type of deployment is heavy deployment and also involves some sort of change to the consensus
  1341. as well. This change does not involve simply changing some platform parameter value, but rather making
  1342. an exogenous change to the platform state or processing logic itself. Such a deployment may be just a set of
  1343. consensus changes that support change in the behavior of a single application or a change in the platform
  1344. that requires a concerted upgrade to a number of different applications simultaneously.
  1345. Both types of deployments are triggered when the group lead submit a proposal based on a release. When
  1346. this proposal is accepted by the council, the application artifacts are replicated to storage and distribution
  1347. infrastructure from the group lead. Installations on consumer devices to automatically and securely update
  1348. 32
  1349. are conducted by first consulting the chain to detect the deployment and then connecting to the distribution
  1350. infrastructure to fetch the payload.
  1351. 15
  1352. Content finance
  1353. The platform has a built-in ecosystem and tools for creators to finance the production of new works through
  1354. flexible crowd funding, which gives backers a stake through a project-specific token. This stake gives the
  1355. right to engage in governance over the project, a possible share of revenue generated by produced assets,
  1356. and possibly the option to trade assets in a market on the platform.
  1357. 15.1
  1358. Working group
  1359. All working group members, including the lead, have the same two sets of responsibilities
  1360. T
  1361. - Curation: Curating the project pool for abusive or non-compliant proposals.
  1362. - Arbitration: Arbitrating disputes in project, where the primary sanctions would be in the form of
  1363. 15.2
  1364. DR
  1365. AF
  1366. banning, redirecting project funds, and slashing organizer stake.
  1367. Project life cycle
  1368. A project is initially created by the prospective project organizer, and this step involves specifying
  1369. - Description: Text, visual, and other assets used for the description of the project.
  1370. - Assets and terms: What final productive assets will be produced, and what claims, if any, do backers
  1371. have on different assets in terms of use and reward.
  1372. - Funding: A description of the funding model of the project, including
  1373. (a) How much is being raised, minimum and maximum
  1374. (b) When do the sales begin and how long do they last.
  1375. (c) How much of the total project stake is up.
  1376. (d) What jurisdictions are allowed to participate in funding.
  1377. - Token: A description of the project token, including
  1378. (a) Name
  1379. (b) Symbol
  1380. (c) Whether it is trade able, if so at what earliest time after end of funding period
  1381. (d) Whether it gives claim on revenue
  1382. (d) Whether it gives claim to govern
  1383. - Claimants: Token allocations to those with claims against the project due to their involvement in the
  1384. production process.
  1385. 33
  1386. The project itself goes through the following states after being submitted:
  1387. - Review: Here, it will be reviewed to see if it is acceptable within the policy of the platform at the
  1388. time.
  1389. - Open: The project becomes visible to the public, and corresponding communication channels become
  1390. available, namely a messaging room and a messaging forum.
  1391. - Funding: Backers can send funds to the project.
  1392. - Production: The raised funds are deployed to create project assets, with the organizer and backers
  1393. collaborating through a governance process. In particular, the funding may be released based on
  1394. milestones.
  1395. - Active: Productive assets are finalized and distributed through the platform and possibly third-party
  1396. platforms also. Any revenue generated by assets distributed on the platform directly will automatically
  1397. T
  1398. pay out claimants based on the given term, possibly subject to governance. Any revenue generated on
  1399. external platforms must be documented and submitted to the project by the organizer. Failure to do
  1400. so will trigger a dispute, and possible sanctions, with the arbitrator.
  1401. DR
  1402. AF
  1403. - Terminated: The project is over in that backers have no further active influence or claims. The terms
  1404. will describe when, or if, this can occur.
  1405. 16
  1406. Advertising
  1407. The platform has a built-in advertising targeting, auction, and delivery system. It allows advertisers to reach
  1408. audiences through a competitive bidding process for display time across a variety of surfaces in consumerfacing experiences. A core premise for a well functioning advertising ecosystem is that a substantial number
  1409. of non-Sybil users are accessing the platform through a well-behaved reference client.
  1410. 16.1
  1411. Working group
  1412. The advertising working group just has a single member, which is the lead, referred to as the advertising
  1413. authority. This role is responsible for running nodes that assist end users in fetching the correct advertising
  1414. campaigns from the auction system, and also settling the state of campaigns upon completion or termination,
  1415. while keeping the display information off the chain.
  1416. 16.2
  1417. Surfaces and targeting
  1418. At any given time, there is a fixed set of such surfaces available, each with its own set of display, interaction,
  1419. and targeting constraints. A separate advertising auction is maintained for each surface, where access
  1420. allocated to the highest cost per impression bid is currently available. There are two families of targeting
  1421. parameters, audience, and session parameters. Audience parameters are those that allow one to target
  1422. consumers based on individual characteristics, such as age interval, gender, location, language, consumption
  1423. history, wallet balance, etc. This information does not go on the chain in clear text, but some of it may be
  1424. stored in the membership settings’ object in encrypted form. Session parameters are those that are specific
  1425. 34
  1426. to the context in which the surface is being displayed, thus identifying media being viewed or searched for,
  1427. or category being browsed, etc.
  1428. While all surfaces can target based on audience parameters, the type of session parameter available
  1429. depends on the surface in question.
  1430. Targeting values will be shared with advertising authority to both select the correct ad and also provide
  1431. confirmation of viewed ads back to the authority; however, this viewing information is never published on
  1432. the chain.
  1433. 16.3
  1434. Campaigns
  1435. A campaign is a bid to occupy a certain surface, subject to a particular set of targeting parameters, at a
  1436. particular price per impression. Specifically, it includes
  1437. • Advertiser identification.
  1438. T
  1439. • Advertising payload matching constraints of given surface.
  1440. • Targeting parameter values matching constraints of the given surface.
  1441. DR
  1442. AF
  1443. • Expiry time.
  1444. • Maximum number of impressions.
  1445. • Price per impression.
  1446. • Funds covering maximum expenditure.
  1447. Once a campaign has been submitted, it lives in a pool of campaigns for the given surface until all the
  1448. funds have been spent; it is then canceled by the advertiser or the platform.
  1449. 16.4
  1450. Delivery
  1451. A given advertising surface has a display policy that prescribes when an end user should repopulate an
  1452. interface (new) content. The following informally describes the steps involved in this process, including a
  1453. user, an advertising authority, and an advertising server.
  1454. • The user sends the signed session and the audience targeting values to the advertising authority.
  1455. • The advertising authority filters the campaign pool for the given surface based on targeting values and
  1456. returns the highest bidding match, with corresponding Merkle inclusion proofs of campaign payload.
  1457. • The user fetches the ad from advertising server and receivesthe receipt token in response.
  1458. • The user sends a receipt including this token, the campaign identifier, and their own key to the
  1459. advertising authority.
  1460. • The user renders advertisement.
  1461. 35
  1462. When an advertising authority detects that a campaign has been displayed enough to exhaust the funds
  1463. locked up, it submits a proof of this to the platform, which also includes information about how many
  1464. impressions have been derived from surfaces that are tied to publisher content and what content has actually
  1465. been shown. This proof is made up of all the receipts from the users that have fetched the given ad. It
  1466. is compressed using the ZkSNARK primitive [11], where the user keys are kept as private inputs. This
  1467. proof can also enforce limits on how many times any given user can at most have submitted a receipt for a
  1468. given ad, preventing trivial abuse from a single member. The chain automatically validates the proof and
  1469. settles the given campaign by burning the funds. The advertiser can cancel the campaign using an analogous
  1470. process. These proofs are further combined to create proofs about the total amount of advertising revenues
  1471. a publisher has a claim over a given period of time.
  1472. 16.5
  1473. Rewards
  1474. The advertising authority receives a payment with two components: a fixed per unit of time payout and a
  1475. T
  1476. payout scaled by proportion of campaign settlements for which proofs are actually submitted. Publishers
  1477. receive a payout from the advertising, not in the traditional staking-based reward, but an unconditional
  1478. value transfer per unit of time. This amount is set to be a given fraction of the total revenue being driven
  1479. 17
  1480. DR
  1481. AF
  1482. through surfaces displaying the content tied to their content.
  1483. Miscellaneous
  1484. 17.1
  1485. Resolving hosts
  1486. Frequently, one may need to resolve host nodes corresponding to an actor on the platform identified with
  1487. a public key. The mapping between this key and the set of active host nodes under the control of the
  1488. given actor is represented in a DHT. The actor registers mutable records of such hosts under a DHT key
  1489. corresponding to the public key. When the set of active nodes changes, simply sign a new message reflecting
  1490. this and store it under the given key. There are many practical implementations of this pattern; for example,
  1491. IPNS or BEP44 in BitTorrent.
  1492. 18
  1493. Discussion
  1494. In this section, various avenues of possible or required research and inquiry are explored.
  1495. - Catastrophic error recovery
  1496. Given the rich-on-chain feature set of the platform and the aspiration to conduct frequent on-chain
  1497. upgrades, the classical blockchain operations model of absolutely never having bugs in production,
  1498. in perpetuity, may be too expensive. Among other costs, this requirement may reduce the speed of
  1499. improvement and encourage a set of trusted developer gatekeepers. These costs are possibly dead
  1500. weight for a protocol that does not intend on emphasizing operational availability and integrity above
  1501. all other objectives. As a result, it may be advisable to investigate various formal and informal protocols
  1502. that may be relied upon to coordinate recovery among validators from some sort of consensus failure.
  1503. 36
  1504. - BRAQ
  1505. The currently described model for BRAQ has at least two short comings.
  1506. First, due to the presence of an inevitably imperfect screening-based membership introduction (see
  1507. section 10), the number of malicious BRAQ instances may silently grow over time. At some point, a
  1508. concerted attack across such memberships can make chain throughput unavailable for some time. If
  1509. such an attack is timed to cover some sensitive time period, it may automatically cause slashing of
  1510. a platform member. This problem can be ameliorated by, for example, introducing sensible default
  1511. transaction inclusion policies that favour non-BRAQ-based transactions or simply by including global
  1512. limits on how many such transactions can be accepted at any given time, perhaps being implemented
  1513. as a BRAQ instance itself.
  1514. Second, the actual quota is not sensitive to payloads involved in actions, only the number of actions.
  1515. This is not fit for a range of different purposes and can easily be amended.
  1516. T
  1517. - ATP
  1518. The obvious problem and risk in using ATP is regarding coming up with a safe time period for a given
  1519. transaction, which may also depend on the payload. Moreover, its not entirely clear how a validator
  1520. DR
  1521. AF
  1522. must treat the scenario where the processing is not finished, despite the time being up. The simplest
  1523. approach is to consider it as any other node failure, such as running out of resources, and simply stop
  1524. the node.
  1525. There is also the opportunity of saving on processing resources by making the current proposal into a
  1526. challenge response protocol. In this alternative approach, the final state can be proposed by anyone,
  1527. subject to some bond, and this proposal can be challenged by anyone during a challenge period. In a
  1528. challenge, all validators can actually conduct the normal ATP processing and, this way, adjudicate the
  1529. final dispute securely. A challenger found to be correct will win the bond.
  1530. Another obvious alternative to the entire ATP approach are things like ZkSNARK [11] and Truebit
  1531. [12]. However, this would impose severe practical limitations on what processing which within scope.
  1532. For ZkSNARK, it will be, at present, infeasible to generate proofs for just about all processing that
  1533. can warrant ATP to begin with, by assumption. For both the approaches, one can almost never reuse
  1534. the existing implementations of the processing in question, even if it is in principle compatible with the
  1535. approach-specific computing model (e.g. WASM or register machine), which is also not always going
  1536. to be the case.
  1537. - Governance
  1538. The current proposal for how governance and elections are organised is relatively naive to obvious
  1539. problems around liveness, vote buying, and validator censorship. This despite governance being at the
  1540. heart of the capabilities of the platform and the incentive compatibility of the protocol every other
  1541. actor faces depends on how effective this process is. Most of the work in this proposal is about how
  1542. to endow a presumed effective governance system with all the assets constituting a functional content
  1543. platform. Further work on incorporating more mature ideas is needed.
  1544. - Screening and suspension and seb 2.0 assets
  1545. 37
  1546. One of the biggest weaknesses of the current proposal is that it may or may not be feasibleto manage
  1547. the integrity of the memberships that are established through screening, in particular since it may be
  1548. difficult to properly identify malicious attacks in production and, even if one could, the corresponding
  1549. screening authority may no longer be bonded. The most obvious solution to this problem is to make a
  1550. screening authority the owner of screened memberships and disable them when the authority unbonds.
  1551. Members could get rescreened with a new authority, using the old keys, in order to preserve their
  1552. membership. This may coincidentally ameliorate one of the other primary limitations of the platform,
  1553. due to the state of current infrastructure, which is the inability to properly own assets such as domains
  1554. and app store entries. An ecosystem of such screeners can own these assets, conduct their own screening
  1555. procedure, and capture in the upside the membership base they bring to the platform.
  1556. - Software development
  1557. Keeping this entire development process has resource costs, not primarily in throughput capacity but
  1558. state size. For example, a very mature large open-source project may have a Git repository that
  1559. T
  1560. occupies dozens of gigabytes in, primarily, commit object blobs. This is not a non-starter, per say,
  1561. but clearly has costs that need to be recognized. There are other approaches, such as the OSCoin
  1562. and the Radicle stack [13], which aim to keep the entire process off chain, extend the Git protocol to
  1563. DR
  1564. AF
  1565. also incorporate the collaborative assets, and delegate consensus to a trusted set of actors. This does
  1566. not satisfy all the outlined requirements and begs the question of how to make the consensus actors
  1567. accountable to the platform; however, it has the benefit of being cheaper on the platform blockchain.
  1568. Another issue requiring further work is how to safely update the platform in concert with user facing
  1569. applications that make assumptions about how the platform functions at any given point of time. This
  1570. is further complicated by the objective of wanting to use the platform itself, as the infrastructure to
  1571. do the application updates.
  1572. - Storage and distribution
  1573. The major problem in the current approach is that all user-downloaded events result in a set of
  1574. transactions and leave a permanent public history of downloads. This is infeasible from both a capacity
  1575. and privacy perspective. The alternative currently being explored involves offloading these transactions
  1576. into a separate chain with trust model based on fraud proofs, and governance to ensure availability,
  1577. inspired by the Plasma framework. [14]. By committing blocks, and in particular state commitments,
  1578. into the main blockchain, it becomes possible to make positive claims about the current state in the
  1579. parallel chain at different times, such as the total amount of data a distributor has moved or the total
  1580. number of downloads for a particular data object. Expired or fraudulent states can be challenged in the
  1581. same way during an exit period. Privacy can be introduced by allowing members to use pseudonymous
  1582. identifier in the parallel chain, which can be proven to match a main chain membership through an
  1583. appropriate ZkSNARK. The disadvantage of this approach is the complexity and latency of main chain
  1584. state changes. An alternative can be to dramatically change the trust model and rely on data being
  1585. shared entirely out of band w.r.t. any shared public state, and then having a voting process-based
  1586. main chain update based on this objective verifiable data.
  1587. A secondary objective is to replace full replication with erasure coding for each data object [15] such
  1588. that less total storage space is required for a given level of fault based on unavailability risk. This
  1589. 38
  1590. makes the storage costs lower.
  1591. References
  1592. [1] Albert O Hirschman. Exit, voice, and loyalty: Responses to decline in firms, organizations, and states,
  1593. volume 25. Harvard university press, 1970.
  1594. [2] Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossip on BFT consensus. CoRR,
  1595. abs/1807.04938, 2018.
  1596. [3] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably
  1597. secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–
  1598. 388. Springer, 2017.
  1599. [4] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling
  1600. T
  1601. byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems
  1602. Principles, SOSP ’17, pages 51–68, New York, NY, USA, 2017. ACM.
  1603. DR
  1604. AF
  1605. [5] E. Buchman J. Kwon. Cosmos - a network of distributed ledgers.
  1606. [6] V. Buterin. Blockchain resource pricing.
  1607. [7] Nick Johnson. Ethereum domain name service - specification.
  1608. [8] J. Poon. Handshake.
  1609. [9] G. Wood. Polkadot: Vision for a heterogeneous multi-chain framework draft 1.
  1610. [10] Bitconi Wiki. Payment channels.
  1611. [11] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct non-interactive zero
  1612. knowledge for a von neumann architecture. In USENIX Security Symposium, pages 781–796, 2014.
  1613. [12] Jason Teutsch and Christian Reitwießner.
  1614. A scalable verification solution for blockchains.
  1615. url:
  1616. https://people. cs. uchicago. edu/teutsch/papers/truebit pdf, 2017.
  1617. [13] OScoin. Radicle, 2019.
  1618. [14] Joseph Poon and Vitalik Buterin. Plasma: Scalable autonomous smart contracts. White paper, 2017.
  1619. [15] Irving S Reed and Gustave Solomon. Polynomial codes over certain finite fields. Journal of the society
  1620. for industrial and applied mathematics, 8(2):300–304, 1960.
  1621. 39