Skip to content
This repository has been archived by the owner on Jan 13, 2025. It is now read-only.

Economic finality modeling via lockout and stake functions #1197

Closed
ericlwilliams opened this issue Sep 12, 2018 · 2 comments
Closed

Economic finality modeling via lockout and stake functions #1197

ericlwilliams opened this issue Sep 12, 2018 · 2 comments
Assignees
Labels
research Open question / topic of discussion

Comments

@ericlwilliams
Copy link
Contributor

ericlwilliams commented Sep 12, 2018

Inspired by the calculations of double-spend attack probabilities as a function of % total hash power and block depth outlined in the bitcoin white paper w/ more detailed analysis here and given that Solana is an availability preferring design - we're interested in:

  • Can we parameterize the economic security of a transaction as a function of vote depth, time, and/or stake
  • What is the value of a dynamic lockout function? i.e. a slashable lockout from voting on alternate histories for a specified POH-duration after a submitted vote. this lockout may grow as a validator accumulates votes on a given branch
  • Can we design an economic finality (i.e. total stake at risk) that is a function of time (e.g. low risk/cost for reversions on order of ~500ms - 1 second w/ increasing stakes in older transactions). This might lower on boarding risk to participate however potential additional attack vector avenues should be considered.

Draft blog posts:
https://docs.google.com/document/d/1DSlFyruaM3-7JrmLx5RBu43MM_qWw4CJAtFcO-oAElc/edit#
https://docs.google.com/document/d/137MGbT_Nx-Hyxnexc2ykbBfPG7nTw45lJihq52Tvxyg/edit#

Light modeling work located https://github.com/solana-labs/research/tree/master/economic_finality_modeling

Some readings:
https://blog.ethereum.org/2016/05/09/on-settlement-finality/
https://medium.com/mechanism-labs/finality-in-blockchain-consensus-d1f83c120a9a
https://github.com/Mechanism-Labs/MetaAnalysis-of-Alternative-Consensus-Protocols
https://medium.com/mechanism-labs/finality-in-blockchain-consensus-d1f83c120a9a

@ericlwilliams ericlwilliams added the research Open question / topic of discussion label Sep 12, 2018
@ericlwilliams ericlwilliams self-assigned this Sep 12, 2018
@ericlwilliams
Copy link
Contributor Author

ericlwilliams commented Sep 20, 2018

@ericlwilliams
Copy link
Contributor Author

Moving to research repo

vkomenda pushed a commit to vkomenda/solana that referenced this issue Aug 29, 2021
)

Bumps [@solana/web3.js](https://github.com/solana-labs/solana-web3.js) from 0.90.5 to 0.91.0.
- [Release notes](https://github.com/solana-labs/solana-web3.js/releases)
- [Commits](solana-labs/solana-web3.js@v0.90.5...v0.91.0)

Signed-off-by: dependabot[bot] <[email protected]>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
brooksprumo pushed a commit to brooksprumo/solana that referenced this issue May 7, 2024
* AccountSharedData::reserve: remove extra alloc + memcpy

Calling data_mut().reserve(additional) used to result in _two_ allocs
and memcpys: the first to unshare the underlying vector, and the second
upon calling reserve since Arc::make_mut clones so it uses capacity ==
len.

With this fix we manually "unshare" allocating with capacity = len +
additional, therefore saving on extra alloc and memcpy.

* AccountSharedData::set_data_from_slice: skip extra alloc + memcpy

We used call make_data_mut() from set_data_from_slice() from the days
when direct mapping couldn't deal with accounts getting shrunk. That
changed in solana-labs#32649 (see the
if callee_account.capacity() < min_capacity check in
cpi.rs:update_caller_account()).

With this change we don't call make_data_mut() anymore before
set_data_from_slice(), saving the cost of a memcpy since
set_data_from_slice() overrides the whole account content anyway.
CriesofCarrots pushed a commit to CriesofCarrots/solana that referenced this issue May 7, 2024
* AccountSharedData::reserve: remove extra alloc + memcpy

Calling data_mut().reserve(additional) used to result in _two_ allocs
and memcpys: the first to unshare the underlying vector, and the second
upon calling reserve since Arc::make_mut clones so it uses capacity ==
len.

With this fix we manually "unshare" allocating with capacity = len +
additional, therefore saving on extra alloc and memcpy.

* AccountSharedData::set_data_from_slice: skip extra alloc + memcpy

We used call make_data_mut() from set_data_from_slice() from the days
when direct mapping couldn't deal with accounts getting shrunk. That
changed in solana-labs#32649 (see the
if callee_account.capacity() < min_capacity check in
cpi.rs:update_caller_account()).

With this change we don't call make_data_mut() anymore before
set_data_from_slice(), saving the cost of a memcpy since
set_data_from_slice() overrides the whole account content anyway.
vovkman pushed a commit to helius-labs/solana that referenced this issue Aug 20, 2024
* AccountSharedData::reserve: remove extra alloc + memcpy

Calling data_mut().reserve(additional) used to result in _two_ allocs
and memcpys: the first to unshare the underlying vector, and the second
upon calling reserve since Arc::make_mut clones so it uses capacity ==
len.

With this fix we manually "unshare" allocating with capacity = len +
additional, therefore saving on extra alloc and memcpy.

* AccountSharedData::set_data_from_slice: skip extra alloc + memcpy

We used call make_data_mut() from set_data_from_slice() from the days
when direct mapping couldn't deal with accounts getting shrunk. That
changed in solana-labs#32649 (see the
if callee_account.capacity() < min_capacity check in
cpi.rs:update_caller_account()).

With this change we don't call make_data_mut() anymore before
set_data_from_slice(), saving the cost of a memcpy since
set_data_from_slice() overrides the whole account content anyway.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
research Open question / topic of discussion
Projects
None yet
Development

No branches or pull requests

1 participant