This repository has been archived by the owner on Jan 13, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Economic finality modeling via lockout and stake functions #1197
Labels
research
Open question / topic of discussion
Comments
Economic finality dashboard WIP: https://solana.shinyapps.io/economic_finality/ |
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.
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:
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
The text was updated successfully, but these errors were encountered: