{"id":44027,"date":"2022-11-26T21:12:21","date_gmt":"2022-11-26T21:12:21","guid":{"rendered":"https:\/\/kaspa.org\/?p=44027"},"modified":"2022-12-27T15:09:23","modified_gmt":"2022-12-27T15:09:23","slug":"kaspa-where-to-part-ii","status":"publish","type":"post","link":"https:\/\/kaspa.org\/kaspa-where-to-part-ii\/","title":{"rendered":"Kaspa where to (Part II)"},"content":{"rendered":"
[et_pb_section fb_built=”1″ _builder_version=”4.16″ global_colors_info=”{}”][et_pb_row _builder_version=”4.16″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″][et_pb_column type=”4_4″ _builder_version=”4.16″ custom_padding=”|||” global_colors_info=”{}” custom_padding__hover=”|||”][et_pb_text _builder_version=”4.19.4″ text_font_size=”16px” text_line_height=”1.4em” background_size=”initial” background_position=”top_left” background_repeat=”repeat” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n
<\/p>\n
<\/p>\n
BY: Yonatan Sompolinsky<\/a><\/p>\n [1] More accurately, one of us was positive throughout that a possibility is within a hand\u2019s reach, and the other was skeptic and believed an impossibility result was lurking in the dark. Interestingly, the roles reversed with respect to the question whether Kaspa can take off. We swore not to reveal the corresponding identities of the weak in faith, but the reader can be assured that between the two of us the truth always lies.<\/p>\n [2] In Bitcoin, where there\u2019s no pruning of historical data, the gap is even larger, due to initial blockchain download that full nodes go through by default when onboarding.<\/p>\n<\/div>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" BY: Yonatan Sompolinsky Crypto winters are warm for projects with character. Last month Michal Sutton and I published the DAGKNIGHT protocol (DK), which to the best of our knowledge is the first POW consensus protocol that is responsive to the network\u2019s actual (*adversarial) latency while being resilient to 49% byzantine attackers. DK is the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":" [1] More accurately, one of us was positive throughout that a possibility is within a hand\u2019s reach, and the other was skeptic and believed an impossibility result was lurking in the dark. Interestingly, the roles reversed with respect to the question whether Kaspa can take off. We swore not to reveal the corresponding identities of the weak in faith, but the reader can be assured that between the two of us the truth always lies.<\/p> [2] In Bitcoin, where there\u2019s no pruning of historical data, the gap is even larger, due to initial blockchain download that full nodes go through by default when onboarding.<\/p><\/div>","_et_gb_content_width":"","inline_featured_image":false},"categories":[27,31,13],"tags":[],"yoast_head":"\n\n
\n
(i) Completing several missing details in the proof section.
(ii) Preparing the paper for peer-review (depends on conference target).
(iii) Devising efficient algorithms \u2014 the current pseudocode is highly inefficient, as it was optimized for ease of reasoning rather than real world implementation.
(iv) Adapting the consensus algorithm to meet additional requirements of an actual cryptocurrency, e.g., the need to regulate minting, control difficulty, and enforce pruning, all of which require a responsive synchronous protocol (rather than DK\u2019s partially synchronous operation mode).<\/li>
(i) One example that comes to mind is flexcaps<\/a>, a proposal to allow miners to create blocks of different sizes and difficulties. While proposed originally for Bitcoin, at high block rates flexcaps require the DK consensus. To see the connection, observe that larger blocks \u2192 higher propagation delay of blocks \u2192 more blocks created in parallel \u2192 wider DAG; and the DK protocol uniquely does not need to bound in advance the width of the DAG, and can cope with it varying even across short timespans. One motivation for flexcap is to support, in times of peak demand, a higher throughput than that which the system can support on average. Indeed, large blocks consume both instantaneous load on the system (CPU, network congestion, etc.) and an accumulating load (larger UTXO \u2192 higher RAM and disk I\/O for later block processing), which justifies a gap between the maximum limit on resource consumption and the average one.\u00b2 This gap is enabled through flexcaps (or through the similar elastic block cap proposal<\/a>).
(ii) Another potential feature is the stealth txns<\/a>, a construction which utilizes<\/em> the asynchrony caused by high bps to protect users from MEV (relevant when smart contracts will be developed). More generally, and still in the context of MEV, the fact that many miners can create a block in the \u201cnext round\u201d, can be utilized to facilitate richer transaction fee mechanisms, in some resemblance to Flashbots\u2019 recent SUAVE<\/a>.<\/li>