jcnelson

Problem

NFTs exist on Ethereum, and we want to "port" them to Stacks. To avoid duplicity, any mechanism that does this will necessary need to do two things:

• Burn the NFT on Ethereum, thereby rendering it un-transferable
• Instantiate the NFT on Stacks

This document sketches a "NFT bridge" system that allows a trusted intermediary to gather burned NFTs on Ethereum and instantiate them on Stacks. The intermediary can grant the NFTs to the original Ethereum owner by sending them to a Stacks address of their choosing (that they would specify as part of burning the NFT), or it can hold on to the newly-ported NFTs and auction them off.

Design Sketch

jcnelson

Problem

For various technical reasons, a given PoX reward cycle can have only so many reward addresses registered. This in turn is what necessitates a high minimum Stacking threshold. The design of the PoX smart contract (which controls this) works around this limitation by providing a way to delegate one's STX to a Stacking delegate, who in turn will Stack all of its clients' STX to clinch reward addresses that the clients could not have obtained individually. The implementation of a Stacking delegate is left unspecified.

This document sketches an implementation that allows anyone to be a Stacking delegate, such that the most economically advantageous action for the delegate is to honestly fulfill its role by gathering and Stacking its clients' STX, collecting the BTC sent to its PoX reward addresses, and disbursing the Bitcoin it receives.

Background

Broadly speaking, delegated Stacking works as follows:

1. The client sends a delegate-stx transaction, indicating a particular Stacking delegate

jcnelson

Preventing Deep Chain Reorganizations from Non-canonical Anchor Blocks

While nodes may be required to re-process all sortitions due to a late-arriving anchor block, nodes do not need to do so eagerly if the anchor block is not part of the canonical Stacks chain. Put another way, if nodes could determine whether or not an anchor block is part of the canonical chain without needing to process any Stacks blocks, then they would not need to reprocess their chainstates if a late-arriving anchor block would not change which Stacks fork was the canonical Stacks chain. The ability to ignore late non-canonical anchor blocks would make the network resilient

jcnelson

Testnet Outage Post-Mortem

From 19 July through 24 July, the Stacks testnet had experienced repeated outages every few hours. The symptom was the repeated recurrence of errors such as the following:

WARN [1595867918.213] [src/chainstate/stacks/db/blocks.rs:2861] [ThreadId(6)] Block 36a6b25fb7dd1775761b80b567425dd886f35272a5cc6a7661df0d99662f9d1c state root mismatch: expected 2fbb24799b4ea08ca50a8a2c75749735a6aa60415758a1394525f789a109067c, got 65fbf51eea07de1a75c5c45373c6aa3c7975e88269948114c0468acbf461cf66

jcnelson

Verifying my Blockstack ID is secured with the address 15gxXgJyT5tM5A4Cbx99nwccynHYsBouzr https://explorer.blockstack.org/address/15gxXgJyT5tM5A4Cbx99nwccynHYsBouzr

jcnelson

Verifying my Blockstack ID is secured with the address 16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg

jcnelson

Keybase proof

I hereby claim:

• I am jcnelson on github.
• I am judecn (https://keybase.io/judecn) on keybase.
• I have a public key ASDSv0l4bYpy4eOMWPxezzyKsadeo5Xxrr5Ulm8Atohfygo

To claim this, I am signing this object:

jcnelson

Verifying that +judecn is my Bitcoin username. You can send me #bitcoin here: https://onename.io/judecn