Getting started with the Nimiq API
This is a prototype of a Python module for simple modification of document files.
A native miner for Nimiq vanity addresses.
A simulator for the Albatross protocol
A Python module that provides multiple anonymization techniques for text (This is only a prototype)
A vanity address miner for Nimiq using key derivation.
Rust implementation of the Nimiq RPC client specs.
Implementation of "Identifying Personal DNA Methylation Profiles by Genotype Inference" by Michael Backes, Pascal Berrang, Matthias Bieg, Roland Eils, Carl Herrmann, Mathias Humbert, Irina Lehmann
Sage scripts to compute various parameters of MNT4/MNT6 curves
Capira RESTful JSON API
issue commentarkworks-rs/algebra
Understand trade-offs of multi-radix domains and FFTs
That sounds like a good idea to me.
- Even after fixing the above, there's still the issue that we only select the larger radix after exhausting all powers in radix-2. As suggested in scipr-lab/zexe#156 (comment), this can result in poor "resizing behaviour", which is demonstrated via the following example:
Required size: 10; GeneralEvaluationDomain: domain_size = 2^4 = 16 DynamicEvaluationDomain: domain_size = 2 * 5 = 10
One question regarding this part: I would imagine that a pure radix-2 FFT is more efficient than a mixed-radix one. So, when the achievable domain sizes are close, a slightly larger radix-2 FFT might be preferable to a mixed-radix one, no? I haven't had a look at the FFTW paper yet, but perhaps they do have some insights into the trade-offs here.
comment created time in 2 days
push eventnimiq/core-rs-albatross
commit sha 277f55f50f0f8026c47e08ab20d4970f0d705d26
Cleanup request response
push time in 18 days
push eventnimiq/core-rs-albatross
commit sha a53a2cacf2ecb72fd2d3527170dd200cc8e8eecc
Add endpoints for history sync
push time in 18 days
push eventnimiq/core-rs-albatross
commit sha bc507470a4f72a9c259b82b2af09b073f77acd74
Add functionality to sync an epoch's history
push time in a month
push eventnimiq/merkle-mountain-range
commit sha 15131885fe7ad701e804d84e7d2874c6f750814f
Only require reference for to-be-hashed leaves
push time in a month
push eventnimiq/core-rs-albatross
commit sha b0eff0c5afd8903115f7051eeca348962448dd35
Fix Store implementation for empty MMRs
push time in a month
push eventnimiq/core-rs-albatross
commit sha 09319cf704d236bd8c47c8278ac879eca74c574b
Use more efficient database representation for MMRs (one entry per node).
push time in a month
push eventnimiq/core-rs-albatross
commit sha 4093d77c2938099ca81bb625b73fc2f3bf1162d4
Use more efficient database representation for MMRs (one entry per node).
push time in a month
push eventpaberr/merkle-mountain-range
commit sha cf0567ea15873d2c443d635a2ff1f6ea415b1606
Create rust.yml
push time in 2 months
push eventpaberr/merkle-mountain-range
commit sha be90358e7c627fdf65847fc2d6c67d08bdb30abc
Merkle Mountain Ranges (documentation/readme missing)
push time in 2 months
push eventpaberr/merkle-mountain-range
commit sha f207a737aca42f85fc7ca26680a501c15fdb5100
Merkle Mountain Ranges (documentation/readme missing)
push time in 2 months
created repositorypaberr/merkle-mountain-range
A Rust implementation of Merkle Mountain Ranges.
created time in 2 months
push eventnimiq/core-rs-albatross
commit sha 7e297b7f3096c3ebb34375c021aea9bf018f06e4
Always compact BitSets after potential removal of elements to obtain a canonical representation.
push time in 2 months
push eventopenredact/anonymizer
commit sha d900cac36100daa466086348058d7298c0efd0e4
Change name for pypi
commit sha bc58e5ddf99d0f49eb37d7df90259be4405b7ec4
Merge branch 'master' of github.com:paberr/anonymizer
push time in 2 months
push eventnimiq/core-rs-albatross
commit sha a6b2b9a524838be3807da068ad245d7ca3bafc47
Incremental merkle trees
commit sha 27ce0cea89a70bcaf3678b3a39d0816fcb8082f3
Allow to remove nodes previously added to the incremental merkle tree
commit sha b2a6bbffc5cac6b0d5322dc4ffd167a96f21c34a
WIP
commit sha 9c6ca21acd5cb6c760aeceaa9d299900077a9bb2
WIP
commit sha 63ee02acfe6d5489821ad335f242de3abdad5b21
WIP2
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 31362c8b9057d7424714144436c0d3f1cb4dccf1
Incremental merkle trees
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 27ce0cea89a70bcaf3678b3a39d0816fcb8082f3
Allow to remove nodes previously added to the incremental merkle tree
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha a6b2b9a524838be3807da068ad245d7ca3bafc47
Incremental merkle trees
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha a145949b547e4e6195a7b58fcbe910238cc8bbd1
Merkle compiles, tests wip
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 2344915723119476cb70c2589e45644b8464eec2
Add new slashed sets to be tracked by the staking contract into the staking contract
push time in 3 months
pull request commentscipr-lab/zexe
Improve Serialization/Deserialization API to use `mut reader/writer: R/W`
The mut reader/writer: R/W change looks good to me. :+1:
comment created time in 3 months
push eventnimiq/core-rs-albatross
commit sha d16c2e0db3d7862a0043a13ee7c0be5393217d82
Macro sync part 1 (sync macro blocks only) Revert micro blocks before syncing isolated macro block Add test for reverting micro blocks
commit sha f63c79b4472f2ba62bcd8422eb2a165ca230191c
WIP
commit sha 110ad1f5e038c44edc0d5a57dc6b5cd36d1b8941
WIP
commit sha f190b5a79de1744509c816d258be705f79ec164a
WIP2
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha d16c2e0db3d7862a0043a13ee7c0be5393217d82
Macro sync part 1 (sync macro blocks only) Revert micro blocks before syncing isolated macro block Add test for reverting micro blocks
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 8cb4678ef88034f9ae1fca1a6c6b5e46e67ed0f0
Update Dockerfile to use latest Ubuntu LTS
commit sha a4f2d1b039c108de0908f2ece592862d720d3a64
Fixes for newer dalek-ed25519 version
commit sha 20687d7fb4a2a14bbf1c1cc6501604898a0d0d7b
Fix typo
commit sha 0bb9b45cd1bf652e460b096fc1eb20cbd0084ee6
Fix clippy warnings
commit sha a4f96b56ce28aea3f9b48bbad84751ae5ee9ec21
Fix get_slot_at when the chain head is at a macro block
commit sha 6d662cf16130b49900b85703ebd3bac34812efe8
Fix deadlock when sending an unpark transaction
commit sha 97e76854e4745fcc6ceecbca2c57b6ad19a9530e
Move validators crate to tokio 0.2
commit sha b73dcc0cbaf5e8c2c59c13b9fb484e20a0014973
Move consensus crate to tokio 0.2
commit sha 5f4e42f40991adf11e1d9e3adf3fb07dda372584
Panic in network implementation if receive would overwrite an existing receive
commit sha de15a3057e17a55e96e0075feac457f2ec01c2dc
Mock network: cleanup test
commit sha 760ff8784710b8c0181dc376d96c391fe3542d47
Remove network-primitives crate * Move PeerAddress to own crate * Move NetworkInfo to own crate * Move ValidatorInfo to validator crate * Move legacy Subscription to own crate * Rename NetworkTime to OffsetTime and move to utils
commit sha 0a45e8fb38adf0bb8ff92d1a5501beb8faa1e3ea
Switch consensus and related crates to network-albatross
commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2
test ci
commit sha 375d8d19d99d374e42ac0146160383d16d6656c0
Remove unused dependencies
commit sha 5de7ee570b8c68cb12bb7efc6bc89ae616cce0de
fix rpc server feature tests
commit sha 611bca0d15c766ffba9455a411655c55a9b0f8c2
fix bls feature tests
commit sha b3c06431b71cb4c48761a00d4bd4c6f4df812b25
fix lib feature tests
commit sha dc1832adb1fe70a91c63e609037536b81d0a3a21
fix blockchain-base feature tests
commit sha ef2e3c136f68fb991e247ba3575da807c6bbba2a
Do not stop receive from all if number of peers drop to 0
commit sha 2c7e99b3aebbbec891ff419ce875515bc1f10cba
Add a comment to motivate previous change
push time in 3 months
Pull request review commentscipr-lab/zexe
Add unchecked serialization/deserialization
macro_rules! impl_prime_field_serializer { reader.read_exact(&mut masked_bytes[..output_byte_size])?; Ok(Self::read(&masked_bytes[..])?) }++ #[allow(unused_qualifications)]+ fn deserialize_unchecked<R: crate::io::Read>(+ reader: &mut R,+ ) -> Result<Self, crate::serialize::SerializationError> {+ const BYTE_SIZE: usize = $byte_size;++ let (_, output_byte_size) =+ crate::serialize::buffer_bit_byte_size($field::<P>::size_in_bits());++ let mut masked_bytes = [0; BYTE_SIZE];+ reader.read_exact(&mut masked_bytes[..output_byte_size])?;+ Ok(Self::read(&masked_bytes[..])?)
This is duplicate code with the deserialize just above.
The default implementation will do the job and the implementation for deserialize_unchecked can be removed.
comment created time in 3 months
Pull request review commentscipr-lab/zexe
Add unchecked serialization/deserialization
macro_rules! impl_prime_field_serializer { fn serialized_size(&self) -> usize { Self::SERIALIZED_SIZE }++ fn serialize_unchecked<W: crate::io::Write>(+ &self,+ writer: &mut W,+ ) -> Result<(), crate::serialize::SerializationError> {+ const BYTE_SIZE: usize = $byte_size;++ let (_, output_byte_size) =+ crate::serialize::buffer_bit_byte_size($field::<P>::size_in_bits());++ let mut bytes = [0u8; BYTE_SIZE];+ self.write(&mut bytes[..])?;++ writer.write_all(&bytes[..output_byte_size])?;+ Ok(())
This code is basically doing the same as the serialize or calling self.serialize_with_flags(writer, crate::serialize::EmptyFlags).
The only difference is the handling of the empty flags.
Did you implement this for performance reasons?
comment created time in 3 months
delete branch nimiq/core-rs-albatross
delete branch : paberr/reward-slash-registry
delete time in 3 months
PR merged nimiq/core-rs-albatross
This PR greatly simplifies what used to be the Reward/Slash registry.
Instead of storing this data in separate databases, we keep the slashes in the ChainInfo object of the ChainStore.
The rewards are now calculated on the fly at each election block.
This PR is built upon #175 and also fixes an issue that arose while reviewing its code.
TODO:
- Finish discussion whether view-changes should impact slot owner selection.
- Finish discussion whether rewards should be distributed per batch instead of per epoch.
pr closed time in 3 months
push eventnimiq/core-rs-albatross
commit sha 2fb118150da23d01c4c0e2aef03cdbd7e1171b2e
Refactor blockchain and remove reward/slash registry
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 2fb118150da23d01c4c0e2aef03cdbd7e1171b2e
Refactor blockchain and remove reward/slash registry
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 26cf4374086bbb513cafdcf5494d29f07eb01949
Intermediate macro blocks (#175)
commit sha efae5a933aeb27facb5ddd0235a1276c31a2ed24
Removed create_macro_extrinsics flag and solved resulting errors. Fixes issue #185.
commit sha 02e6eff7530c4f2514ce63082804be7a4b56b98a
Removed unstaking delay (in micro blocks) and also solved an error where unstaking would happen after the next macro block (instead of at the next election macro block). Fixes issue #184.
commit sha 8b68de3dbecf1f706fd048be9285ea01340a3aea
1. Added OffsetTime back to Blockchain. 2. Added timestamp checks to verify_block_header in blockchain.rs in crate blockchain-albatross. 3. Added function timestamp in Block. It simply returns the timestamp of the block. 4. Added the constant TIMESTAMP_MAX_DRIFT to policy.rs. It defines the maximum drift allowed in the future for a block timestamp. This effectively replaces PR #171.
commit sha 44253aeddee2312a30b023fab481759f63bdad3f
Removed Argon2d and SHA512 from the hash algorithms options for the HTLC contract.
commit sha 9324f3c141076894d869002cb915184e77387682
Refactor blockchain and remove reward/slash registry
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 4721d1dbc921a5c83f61309c33e3f63201245807
Refactor blockchain and remove reward/slash registry
push time in 3 months
issue commentnimiq/core-rs-albatross
Improving rewards and punishments with checkpoint macro blocks
Here's the result of today's discussion and how we intend to work with misbehaving validators in the future:
Slashing Behaviour
General Behaviour:
- On misbehaviour (view changes, fork proofs) validators are marked as disabled slot, lost reward and parked in the staking contract. The first two sets apply only to slots, while parking applies to the whole validator.
- Except for this, the misbehaviour doesn’t have any implications on the current batch.
- At the transition between batches (i.e., in the macro blocks), the current set of disabled slots is retrieved from the staking contract and from then on has impact on which slots are eligible for block production. That means that both fork proofs and view changes barr validators from producing blocks in a certain slot starting from the following batch.
- Validators can send an unslashing transaction at any time, which removes them from both the parked and the disabled slots sets. If the transaction is sent between the misbehaviour and the next macro block, no barring from block production occurs.
- The misbehaving slots will never receive rewards for the batch it occurred in. More precisely, all slots in lost reward bitwise or disabled slots will not receive rewards. Note that these rewards of batch i are payed out at the end of batch i+1 only. After paying out the rewards for a batch, its lost reward set is reset. We thus need to keep track of two sets for lost rewards (current batch and previous batch).
- Assuming misbehaviour in epoch j, if no unslashing transaction happens within epoch j or j+1, the whole validator will be put inactive at the end of epoch j+1. This is what the parking set is for.
Nomenclature:
- Disabled slots: The set of slots that is punished for misbehaviour by barring these slots from block production. This set is only reset after each election block.
- Lost reward: The set of slots that tracks which slots are definitely ineligible to receive rewards in the next batch. Note that every slot on the disabled slots set is also not receiving any rewards. The lost rewards set is reset after distributing the respective rewards. Unslashing transactions do not have an impact on this set. This ensures that misbehaving slots lose their rewards at least once.
- Unslashing transaction: Also called unparking transaction. This is a transaction a validator can send to prevent them from being put inactive and reactivates their ability to produce blocks (i.e., removes them from the parked set and disabled slots set).
- Parking: Parking denotes the temporary state of a validator being marked to be inactivated. If a validator is parked, it will be put inactive after one full epoch of grace period. A validator can prevent this by sending an unparking transaction.
Details:
- Slashes are stored in the staking contract (applied with view change inherent) and can be unslashed there
- The staking contract needs to store (slot, public key) in order to be able to remove slots from the disabled slots set upon unslashing transactions (which only contain the public key).
- We need to make sure you always loose rewards even if you remove yourself from the slashed set for block production, that’s why we distinguish between lost rewards and disabled slots.
- The disabled slots set (as well as the lost reward and parked sets) is updated immediately with the inherent generated by the misbehaviour. The effective set used for the slot calculation, however, is only read after each macro block. Thus, while the staking contract immediately reflects the changes, the punishment only comes into effect after the end of the batch.
- This delay keeps the effective disabled slots set constant during each batch and allows to predict the correct slot owner at any point during the batch when the previous seed is known.
- For optimisation, we put the disabled slots set of the closing batch into the inherents of the macro block.
Example:
Epoch j, batch i, block k: A view change occurs. This view change generates an inherent that modifies the staking contract, adding the slot to the lost reward and disabled slots sets and putting the validator on the parked list.
At the next macro block: The effective disabled slots for block production are read from the staking contract. These will be active from the beginning of the next batch (barring the slot from producing blocks). Unslashing in batch i would result in the slot not being part of the effective disabled slots for block production read at this macro block. Unslashing in batch i+1 would take effect only after next macro block (in batch i+2).
Parking works independently and follows the same pattern it does now. Without an unslashing transaction, the validator will be put inactive at the election block of epoch j+1 (taking effect from epoch j+2).
Note: We want that the validator cannot be chosen for epoch j+2, we need to make sure that the validator selection is run after committing the accounts tree state.
comment created time in 3 months
PR opened nimiq/core-rs-albatross
This PR greatly simplifies what used to be the Reward/Slash registry.
Instead of storing this data in separate databases, we keep the slashes in the ChainInfo object of the ChainStore.
The rewards are now calculated on the fly at each election block.
This PR is built upon #175 and also fixes an issue that arose while reviewing its code.
TODO:
- Finish discussion whether view-changes should impact slot owner selection.
- Finish discussion whether rewards should be distributed per batch instead of per epoch.
pr created time in 3 months
create barnchnimiq/core-rs-albatross
branch : paberr/reward-slash-registry
created branch time in 3 months
pull request commentnimiq/core-rs-albatross
While refactoring the whole slash registry/reward registry thing, I realised that we do need to include both slashed sets in the election blocks.
Previous to this PR, election blocks only contained the slashed set of the previous epoch (not the current one that ends with the block at hand). This was and is required for syncing, so that rewards can be calculated correctly.
This PR now added the current slashed set to macro blocks that are no election blocks. However, consider the following scenario: I synced up to the latest election block and start producing blocks. The election block didn't include the "current epoch" slashed set (which now after beginning the next epoch is the "previous epoch" slashed set). So, upon arriving at the first checkpoint block, this information is missing.
I'll address this issue in my follow up PR that refactors said code.
comment created time in 3 months
push eventnimiq/core-rs-albatross
commit sha 2c7e99b3aebbbec891ff419ce875515bc1f10cba
Add a comment to motivate previous change
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha ef2e3c136f68fb991e247ba3575da807c6bbba2a
Do not stop receive from all if number of peers drop to 0
push time in 3 months
delete branch nimiq/core-rs-albatross
delete branch : sebastian/feature-tests
delete time in 3 months
PR merged nimiq/core-rs-albatross
Pull request checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I have resolved any merge conflicts.
What's in this pull request?
This PR makes script/test_features.py work again
pr closed time in 3 months
push eventnimiq/core-rs-albatross
commit sha 5de7ee570b8c68cb12bb7efc6bc89ae616cce0de
fix rpc server feature tests
commit sha 611bca0d15c766ffba9455a411655c55a9b0f8c2
fix bls feature tests
commit sha b3c06431b71cb4c48761a00d4bd4c6f4df812b25
fix lib feature tests
commit sha dc1832adb1fe70a91c63e609037536b81d0a3a21
fix blockchain-base feature tests
push time in 3 months
PR closed nimiq/core-rs-albatross
pr closed time in 3 months
push eventnimiq/core-rs-albatross
commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2
test ci
commit sha 375d8d19d99d374e42ac0146160383d16d6656c0
Remove unused dependencies
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2
test ci
commit sha 375d8d19d99d374e42ac0146160383d16d6656c0
Remove unused dependencies
commit sha 5de7ee570b8c68cb12bb7efc6bc89ae616cce0de
fix rpc server feature tests
commit sha 611bca0d15c766ffba9455a411655c55a9b0f8c2
fix bls feature tests
commit sha b3c06431b71cb4c48761a00d4bd4c6f4df812b25
fix lib feature tests
commit sha dc1832adb1fe70a91c63e609037536b81d0a3a21
fix blockchain-base feature tests
push time in 3 months
push eventnimiq/core-rs-albatross
commit sha 375d8d19d99d374e42ac0146160383d16d6656c0
Remove unused dependencies
push time in 3 months
PR merged nimiq/core-rs-albatross
Pull request checklist
- [x] All tests pass. Demo project builds and runs.
- [x] I have resolved any merge conflicts.
What's in this pull request?
Replaces Box::into_raw_non_null(...) with NonNull:from(Box::leak(...)) so that the ci can run again.
pr closed time in 3 months
push eventnimiq/core-rs-albatross
commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2
test ci
push time in 3 months
issue commentnimiq/core-rs-albatross
[FEATURE REQUEST] RPC functions for better staking pool support
Ok thanks, that makes it clearer. Then, what I wrote above applies and retrieving the general list of stakes at a specified point in time is very expensive from a computational point of view.
In my opinion, there are two ways to go from here that make possible what you are looking for:
-
Move this functionality to the outside (i.e., into the pool implementation) and store the list of stakes for your pool as you go. What I mean by that is that we could expose events that notify you when, e.g., a macro block happened. Then, you can retrieve the list of stakes for that macro block and store it in your database. (Potentially, the event itself could actually already include the list of stakes, but we would have to see what makes sense; also see below.)
-
We provide a RPC function (which is still taking up some computation) that retrieves the stakes by reverting only transactions affecting the staking contract. Such a function should not be called regularly but only if actually needed. Also, implementing this would certainly take some time.
Overall, I think option 1 is perhaps the better way to go as I am a bit at unease with exposing computational heavy functions via RPC. :) It is also the easier way to implement it and allows you to retrieve the information for the past very efficiently. I'm thinking of some way to subscribe to stake changes for a particular validator public key for example. So, you would get all of the changes while they occur and can keep your own history in a database. This should be possible via a websocket RPC.
I'd be interested in whether option would 1 work for you. Or do you foresee issues with that?
comment created time in 3 months
push eventnimiq/core-rs-albatross
commit sha 5f4e42f40991adf11e1d9e3adf3fb07dda372584
Panic in network implementation if receive would overwrite an existing receive
push time in 3 months
Pull request review commentnimiq/core-rs-albatross
impl Blockchain { return Err(PushError::InvalidSuccessor); } - // Check if a view change occurred - if so, validate the proof+ // Check that the current block timestamp is equal or greater than the timestamp of the+ // previous block. This is necessary to guarantee that time is monotonically increasing.+ // Having time go back could create issues with the blockchain state.+ if prev_info.head.timestamp() >= header.timestamp() {+ warn!("Rejecting block - block timestamp precedes parent timestamp");+ return Err(PushError::InvalidSuccessor);+ }++ // Check that the current block timestamp less the node's system time is less than or equal+ // to the allowed maximum drift. Basically, we check that the block isn't from the future.+ // This is necessary so that validators cannot create blocks far in the future, which would+ // give them bigger rewards.+ // Both times are given in Unix time standard.+ let now = SystemTime::now()+ .duration_since(SystemTime::UNIX_EPOCH)+ .expect("System time is before Unix epoch")+ .as_millis() as u64;
We usually want to rely on the NetworkTime instead of our local SystemTime.
comment created time in 3 months
push eventnimiq/core-rs-albatross
commit sha 56418734d7176ef6d4833c37a61e87fb16ac7d09
Macro sync part 1 (sync macro blocks only)
commit sha cc5386226050be4d0f2f85ce0105e8e17b5fbf73
Revert micro blocks before syncing isolated macro block
commit sha c94c10ee222d626b2a5eb332069f51cf452aa347
Add test for reverting micro blocks
push time in 3 months
issue commentnimiq/core-rs-albatross
[FEATURE REQUEST] RPC functions for better staking pool support
Hi,
first of all, thank you for the detailed explanation! The first feature seems to be quite straightforward to implement and we'll add it onto our list of TODOs. The second one, I need a bit more information for.
Feature 1: RPC function for rewards
There already should be everything in place to be able to implement this feature.
To calculate the total reward for an epoch, we need the transactions and timestamps of the epoch's macro block and the preceding epoch's macro block. Both should be easily retrievable from the blockchain (even with the current version of macro sync that we're planning). To calculate the individual rewards, we additionally need the validators of the epoch and the slash set, which are also stored within the macro blocks.
Feature 2: RPC function for stakes
Okay, here I will need some more information what exactly you plan to retrieve. For now, I assume you want something similar to the listStakes we currently have.
Unfortunately, this is information that can change per block. When you say you would like to get this information for a specific epoch, do you mean the snapshot that is used to select the validators for this epoch (i.e. the state before the previous macro block)?
In general, this kind of information can only be computed by temporarily reverting the transactions that affect the staking contract. This is quite some heavy operation. A naive implementation could just open a database transaction and revert all blocks before retrieving the staking contract and aborting the database transaction. This approach would currently fail as we disallow to revert macro blocks. A more efficient implementation would probably only revert what affects the staking contract, which, however, is more difficult to implement.
Or do you actually mean you want to be able to retrieve the validators of the epoch and their relative stake (i.e., the voting power)? This is actually part of the macro blocks and thus quite easy to compute.
Perhaps, if you tell us what specific information in the stakes you are looking for, we could find a more efficient solution though. :)
comment created time in 3 months