SIMD-0109: Add a tipping mechanism to send SOL to the current leader

[buffalu]

Transactions prioritized out of band can't dynamically tip SOL to the leader in protocol.

This SIMD addresses that by setting some context on why this is helpful and solves it with the addition of a Native Program, the Tip Program.

[aeyakovenko]

Why not any asset?

I think this can be accomplished by just formalizing a public key with a known private key that all the leaders can use to sweep arbitrary tips

[buffalu]

Why not any asset?

I think this can be accomplished by just formalizing a public key with a known private key that all the leaders can use to sweep arbitrary tips

at first glance this would single threads the runtime.

[buffalu]

Why not any asset?
I think this can be accomplished by just formalizing a public key with a known private key that all the leaders can use to sweep arbitrary tips

at first glance this would single threads the runtime.

it would be interesting to think if there's a way to do this with many tokens w/o single threading the runtime though... could you just do an on-chain swap + tip in SOL?

[t-nelson]

yes it would either force serial execution or require on-demand accounts loading (which people think they want, but they don't). lamports are the only thing that we can unilaterally credit

[t-nelson]

i don't think this actually needs any new program, just a syscall to credit the leader and a new system program instruction that wraps it for convenience (tx introspection, really). syscall accumulates lamports in the tx context. end of batch tx context accumulators are collated into an atomic in the bank. end of slot, pay out to leader collector address, same as tx fees.

---

if we really need the ability to specify a custom collector address, imo that's a separate simd and extends the vote account

[buffalu]

end of slot, pay out to leader collector address, same as tx fees.

what are you imagining the leader collector address is w/o the custom collector address? the identity/authorized voter?

[t-nelson]

what are you imagining the leader collector address is w/o the custom collector address? the identity/authorized voter?

active authorized voter, just like today (which is the identity if the operator is mildly competent)

[buffalu]

what are you imagining the leader collector address is w/o the custom collector address? the identity/authorized voter?

active authorized voter, just like today (which is the identity if the operator is mildly competent)

ack on two SIMDs. that's fine with me. will look closer at your suggested method of using syscall but at first glance seems reasonable

[buffalu]

notes from discord i need to add:

alternatives considered:

• could use something similar to incinerator
• run into similar issues here: https://web.archive.org/web/20220202165147/https://opcodes.fr/en/publications/2022-01/detecting-transaction-simulation/

[SOELTH]

Thanks for the proposal good sir 🚀

Main two pain points for me are:

• I don't think the validator should have a singular tip receiver. This forces sequential execution of otherwise independent txs and will undoubtedly cause a lot of write lock contention. We definitely want a way to allow searchers to tip the validator in parallel. I don't necessarily love the idea of creating a bunch of new accounts either. Allocating/loading unique accounts repeatedly is also expensive. I'll think about this problem more and follow up.

• The rust syntax 💀

[buffalu]

Thanks for the proposal good sir 🚀

Main two pain points for me are:

• I don't think the validator should have a singular tip receiver. This forces sequential execution of otherwise independent txs and will undoubtedly cause a lot of write lock contention. We definitely want a way to allow searchers to tip the validator in parallel. I don't necessarily love the idea of creating a bunch of new accounts either. Allocating/loading unique accounts repeatedly is also expensive. I'll think about this problem more and follow up.
• The rust syntax 💀

agree on all the points above. hoping with this syscall and/or credit-only account that accumulates into AtomicU64 can help remove the sequential execution piece!

[SOELTH]

Thanks for the proposal good sir 🚀
Main two pain points for me are:

• I don't think the validator should have a singular tip receiver. This forces sequential execution of otherwise independent txs and will undoubtedly cause a lot of write lock contention. We definitely want a way to allow searchers to tip the validator in parallel. I don't necessarily love the idea of creating a bunch of new accounts either. Allocating/loading unique accounts repeatedly is also expensive. I'll think about this problem more and follow up.
• The rust syntax 💀

agree on all the points above. hoping with this syscall and/or credit-only account that accumulates into AtomicU64 can help remove the sequential execution piece!

Can you elaborate on the idea of the AtomicU64? I don't even think this has to be strictly "atomic", perse. Since state is only hashed at the end of each block, I assume this is an account where a valid tx can declare an "add" or a "sub" to this account and the balances are totaled at the end of the block when state is hashed?

Follow up: I don't like the name "Atomic", but I agree that each individual executor thread can just track the balances and we can add them mux-style at the end of the block before state is hashed.

So from a protocol level we can give searchers/validators the ability to declare their intention to tip/withdraw SOL from the account by the end of the block in which it's included. Reads of the account could return total value from the previous block.

[esemeniuc]

either stored in votestate: where is the other location?

[esemeniuc]

could you provide a simple example?

[lheeger-jump]

Why not add a new Sysvar which any lamports are sweeped to the leader?

[buffalu]

Why not add a new Sysvar which any lamports are sweeped to the leader?

that works for me and is what @t-nelson suggested here.

for someone working on firedancer, does that seem like a reasonable approach to you? if so, will rewrite the proposal with that in mind!

[t-nelson]

superseded as per #109 (comment)