profile
viewpoint

nimiq/nimiq-demo 30

Getting started with the Nimiq API

openredact/expose-text 12

This is a prototype of a Python module for simple modification of document files.

paberr/nimiq-vanity-miner 8

A native miner for Nimiq vanity addresses.

nimiq/albatross-simulator 6

A simulator for the Albatross protocol

openredact/anonymizer 5

A Python module that provides multiple anonymization techniques for text (This is only a prototype)

paberr/nimiq-address-miner 3

A vanity address miner for Nimiq using key derivation.

nimiq-community/rust-client 1

Rust implementation of the Nimiq RPC client specs.

paberr/ciphermed-forests 1

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

paberr/mnt4-mnt6-scripts 1

Sage scripts to compute various parameters of MNT4/MNT6 curves

capira-videos/capira-api 0

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.

Pratyush

comment created time in 2 days

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 277f55f50f0f8026c47e08ab20d4970f0d705d26

Cleanup request response

view details

push time in 18 days

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha a53a2cacf2ecb72fd2d3527170dd200cc8e8eecc

Add endpoints for history sync

view details

push time in 18 days

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha bc507470a4f72a9c259b82b2af09b073f77acd74

Add functionality to sync an epoch's history

view details

push time in a month

push eventnimiq/merkle-mountain-range

Pascal Berrang

commit sha 15131885fe7ad701e804d84e7d2874c6f750814f

Only require reference for to-be-hashed leaves

view details

push time in a month

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha b0eff0c5afd8903115f7051eeca348962448dd35

Fix Store implementation for empty MMRs

view details

push time in a month

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 09319cf704d236bd8c47c8278ac879eca74c574b

Use more efficient database representation for MMRs (one entry per node).

view details

push time in a month

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 4093d77c2938099ca81bb625b73fc2f3bf1162d4

Use more efficient database representation for MMRs (one entry per node).

view details

push time in a month

MemberEvent

push eventpaberr/merkle-mountain-range

Pascal Berrang

commit sha cf0567ea15873d2c443d635a2ff1f6ea415b1606

Create rust.yml

view details

push time in 2 months

push eventpaberr/merkle-mountain-range

Pascal Berrang

commit sha be90358e7c627fdf65847fc2d6c67d08bdb30abc

Merkle Mountain Ranges (documentation/readme missing)

view details

push time in 2 months

push eventpaberr/merkle-mountain-range

Pascal Berrang

commit sha f207a737aca42f85fc7ca26680a501c15fdb5100

Merkle Mountain Ranges (documentation/readme missing)

view details

push time in 2 months

create barnchpaberr/merkle-mountain-range

branch : main

created branch 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

Pascal Berrang

commit sha 7e297b7f3096c3ebb34375c021aea9bf018f06e4

Always compact BitSets after potential removal of elements to obtain a canonical representation.

view details

push time in 2 months

push eventopenredact/anonymizer

Pascal Berrang

commit sha d900cac36100daa466086348058d7298c0efd0e4

Change name for pypi

view details

Pascal Berrang

commit sha bc58e5ddf99d0f49eb37d7df90259be4405b7ec4

Merge branch 'master' of github.com:paberr/anonymizer

view details

push time in 2 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha a6b2b9a524838be3807da068ad245d7ca3bafc47

Incremental merkle trees

view details

Pascal Berrang

commit sha 27ce0cea89a70bcaf3678b3a39d0816fcb8082f3

Allow to remove nodes previously added to the incremental merkle tree

view details

Pascal Berrang

commit sha b2a6bbffc5cac6b0d5322dc4ffd167a96f21c34a

WIP

view details

Pascal Berrang

commit sha 9c6ca21acd5cb6c760aeceaa9d299900077a9bb2

WIP

view details

Pascal Berrang

commit sha 63ee02acfe6d5489821ad335f242de3abdad5b21

WIP2

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 31362c8b9057d7424714144436c0d3f1cb4dccf1

Incremental merkle trees

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 27ce0cea89a70bcaf3678b3a39d0816fcb8082f3

Allow to remove nodes previously added to the incremental merkle tree

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha a6b2b9a524838be3807da068ad245d7ca3bafc47

Incremental merkle trees

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha a145949b547e4e6195a7b58fcbe910238cc8bbd1

Merkle compiles, tests wip

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 2344915723119476cb70c2589e45644b8464eec2

Add new slashed sets to be tracked by the staking contract into the staking contract

view details

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:

Pratyush

comment created time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

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

view details

Pascal Berrang

commit sha f63c79b4472f2ba62bcd8422eb2a165ca230191c

WIP

view details

Pascal Berrang

commit sha 110ad1f5e038c44edc0d5a57dc6b5cd36d1b8941

WIP

view details

Pascal Berrang

commit sha f190b5a79de1744509c816d258be705f79ec164a

WIP2

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

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

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Jeffrey Esquivel S

commit sha 8cb4678ef88034f9ae1fca1a6c6b5e46e67ed0f0

Update Dockerfile to use latest Ubuntu LTS

view details

Jeffrey Esquivel S

commit sha a4f2d1b039c108de0908f2ece592862d720d3a64

Fixes for newer dalek-ed25519 version

view details

Jeffrey Esquivel S

commit sha 20687d7fb4a2a14bbf1c1cc6501604898a0d0d7b

Fix typo

view details

Jeffrey Esquivel S

commit sha 0bb9b45cd1bf652e460b096fc1eb20cbd0084ee6

Fix clippy warnings

view details

Jeffrey Esquivel S

commit sha a4f96b56ce28aea3f9b48bbad84751ae5ee9ec21

Fix get_slot_at when the chain head is at a macro block

view details

Sergio Valverde

commit sha 6d662cf16130b49900b85703ebd3bac34812efe8

Fix deadlock when sending an unpark transaction

view details

Sergio Valverde

commit sha 97e76854e4745fcc6ceecbca2c57b6ad19a9530e

Move validators crate to tokio 0.2

view details

Sergio Valverde

commit sha b73dcc0cbaf5e8c2c59c13b9fb484e20a0014973

Move consensus crate to tokio 0.2

view details

Pascal Berrang

commit sha 5f4e42f40991adf11e1d9e3adf3fb07dda372584

Panic in network implementation if receive would overwrite an existing receive

view details

styppo

commit sha de15a3057e17a55e96e0075feac457f2ec01c2dc

Mock network: cleanup test

view details

styppo

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

view details

styppo

commit sha 0a45e8fb38adf0bb8ff92d1a5501beb8faa1e3ea

Switch consensus and related crates to network-albatross

view details

Sebastian

commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2

test ci

view details

Sebastian

commit sha 375d8d19d99d374e42ac0146160383d16d6656c0

Remove unused dependencies

view details

Sebastian

commit sha 5de7ee570b8c68cb12bb7efc6bc89ae616cce0de

fix rpc server feature tests

view details

Sebastian

commit sha 611bca0d15c766ffba9455a411655c55a9b0f8c2

fix bls feature tests

view details

Sebastian

commit sha b3c06431b71cb4c48761a00d4bd4c6f4df812b25

fix lib feature tests

view details

Sebastian

commit sha dc1832adb1fe70a91c63e609037536b81d0a3a21

fix blockchain-base feature tests

view details

Pascal Berrang

commit sha ef2e3c136f68fb991e247ba3575da807c6bbba2a

Do not stop receive from all if number of peers drop to 0

view details

Pascal Berrang

commit sha 2c7e99b3aebbbec891ff419ce875515bc1f10cba

Add a comment to motivate previous change

view details

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.

Pratyush

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?

Pratyush

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

Refactor Reward/Slash Registry

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.
+529 -1010

0 comment

16 changed files

paberr

pr closed time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 2fb118150da23d01c4c0e2aef03cdbd7e1171b2e

Refactor blockchain and remove reward/slash registry

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 2fb118150da23d01c4c0e2aef03cdbd7e1171b2e

Refactor blockchain and remove reward/slash registry

view details

push time in 3 months

push eventnimiq/core-rs-albatross

nibhar

commit sha 26cf4374086bbb513cafdcf5494d29f07eb01949

Intermediate macro blocks (#175)

view details

brunoffranca

commit sha efae5a933aeb27facb5ddd0235a1276c31a2ed24

Removed create_macro_extrinsics flag and solved resulting errors. Fixes issue #185.

view details

brunoffranca

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.

view details

brunoffranca

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.

view details

brunoffranca

commit sha 44253aeddee2312a30b023fab481759f63bdad3f

Removed Argon2d and SHA512 from the hash algorithms options for the HTLC contract.

view details

Pascal Berrang

commit sha 9324f3c141076894d869002cb915184e77387682

Refactor blockchain and remove reward/slash registry

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 4721d1dbc921a5c83f61309c33e3f63201245807

Refactor blockchain and remove reward/slash registry

view details

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.

brunoffranca

comment created time in 3 months

PR opened nimiq/core-rs-albatross

Refactor Reward/Slash Registry

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.
+1261 -1152

0 comment

60 changed files

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

Intermediate macro blocks

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.

nibhar

comment created time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 2c7e99b3aebbbec891ff419ce875515bc1f10cba

Add a comment to motivate previous change

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha ef2e3c136f68fb991e247ba3575da807c6bbba2a

Do not stop receive from all if number of peers drop to 0

view details

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

Reviewers
Fix feature tests

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

+7 -3

0 comment

5 changed files

nibhar

pr closed time in 3 months

push eventnimiq/core-rs-albatross

Sebastian

commit sha 5de7ee570b8c68cb12bb7efc6bc89ae616cce0de

fix rpc server feature tests

view details

Sebastian

commit sha 611bca0d15c766ffba9455a411655c55a9b0f8c2

fix bls feature tests

view details

Sebastian

commit sha b3c06431b71cb4c48761a00d4bd4c6f4df812b25

fix lib feature tests

view details

Sebastian

commit sha dc1832adb1fe70a91c63e609037536b81d0a3a21

fix blockchain-base feature tests

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Sebastian

commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2

test ci

view details

Sebastian

commit sha 375d8d19d99d374e42ac0146160383d16d6656c0

Remove unused dependencies

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Sebastian

commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2

test ci

view details

Sebastian

commit sha 375d8d19d99d374e42ac0146160383d16d6656c0

Remove unused dependencies

view details

Sebastian

commit sha 5de7ee570b8c68cb12bb7efc6bc89ae616cce0de

fix rpc server feature tests

view details

Sebastian

commit sha 611bca0d15c766ffba9455a411655c55a9b0f8c2

fix bls feature tests

view details

Sebastian

commit sha b3c06431b71cb4c48761a00d4bd4c6f4df812b25

fix lib feature tests

view details

Sebastian

commit sha dc1832adb1fe70a91c63e609037536b81d0a3a21

fix blockchain-base feature tests

view details

push time in 3 months

push eventnimiq/core-rs-albatross

Sebastian

commit sha 375d8d19d99d374e42ac0146160383d16d6656c0

Remove unused dependencies

view details

push time in 3 months

delete branch nimiq/core-rs-albatross

delete branch : sebastian/ci-test

delete time in 3 months

PR merged nimiq/core-rs-albatross

Reviewers
Replace Box::into_raw_non_null(...) with NonNull:from(Box::leak(...))

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.

+4 -5

0 comment

2 changed files

nibhar

pr closed time in 3 months

push eventnimiq/core-rs-albatross

Sebastian

commit sha fa104bd558f53eea2c492e9d3bef827a4284cdb2

test ci

view details

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:

  1. 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.)

  2. 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?

redmaner

comment created time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 5f4e42f40991adf11e1d9e3adf3fb07dda372584

Panic in network implementation if receive would overwrite an existing receive

view details

push time in 3 months

Pull request review commentnimiq/core-rs-albatross

Block timestamps checks

 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.

brunoffranca

comment created time in 3 months

push eventnimiq/core-rs-albatross

Pascal Berrang

commit sha 56418734d7176ef6d4833c37a61e87fb16ac7d09

Macro sync part 1 (sync macro blocks only)

view details

Pascal Berrang

commit sha cc5386226050be4d0f2f85ce0105e8e17b5fbf73

Revert micro blocks before syncing isolated macro block

view details

Pascal Berrang

commit sha c94c10ee222d626b2a5eb332069f51cf452aa347

Add test for reverting micro blocks

view details

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. :)

redmaner

comment created time in 3 months

more