Skip to content

Commit

Permalink
Homogenise types to int64
Browse files Browse the repository at this point in the history
See discussion here #34 (comment)
  • Loading branch information
JustinDrake authored Oct 3, 2018
1 parent 0941d59 commit 0c0b7b7
Showing 1 changed file with 12 additions and 10 deletions.
22 changes: 12 additions & 10 deletions specs/beacon-chain.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,7 @@ A `SpecialObject` looks as follows:

```python
fields = {
'type': 'int8',
'type': 'int64',
'data': ['bytes']
}
```
Expand All @@ -121,7 +121,7 @@ fields = {
# Slot number
'slot': 'int64',
# Shard ID
'shard_id': 'int16',
'shard_id': 'int64',
# List of block hashes that this signature is signing over that
# are NOT part of the current chain, in order of oldest to newest
'oblique_parent_hashes': ['hash32'],
Expand Down Expand Up @@ -195,15 +195,15 @@ fields = {
'pubkey': 'int256',
# What shard the validator's balance will be sent to
# after withdrawal
'withdrawal_shard': 'int16',
'withdrawal_shard': 'int64',
# And what address
'withdrawal_address': 'address',
# The validator's current RANDAO beacon commitment
'randao_commitment': 'hash32',
# Current balance
'balance': 'int128',
# Current balance in Gwei
'balance': 'int64',
# Status (see status codes in constants above)
'status': 'int8',
'status': 'int64',
# Slot where this validator leaves
'exit_slot': 'int64'
}
Expand All @@ -214,12 +214,14 @@ A `ShardAndCommittee` object is of the form:
```python
fields = {
# The shard ID
'shard_id': 'int16',
'shard_id': 'int64',
# Validator indices
'committee': ['int24']
'committee': ['int64']
}
```

**Implementation note**: For design simplicity and homogenity the spec uses the `int64` type even when smaller bit widths (e.g. `int32` or `int16`) are possible. This does not preclude implementations from using optimised types internally. For example in `ShardAndCommittee` above, one may use `int16` for `shard_id` and `int24` for `committee`.

And a `CrosslinkRecord` contains information about the last fully formed crosslink to be submitted into the chain:

```python
Expand Down Expand Up @@ -533,8 +535,8 @@ Let `committees` be the set of committees processed and `time_since_last_confirm

For each `SpecialObject` `obj` in `active_state.pending_specials`:

* **[covers logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int32` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot`
* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int32` values where each value represents an index into `validators`, `data[1]` as the data being signed and `data[2]` as an aggregate signature. Interpret `data[3:6]` similarly. Verify that both signatures are valid, that the two signatures are signing distinct data, and that they are either signing the same slot number, or that one surrounds the other (ie. `source1 < source2 < target2 < target1`). Let `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then:
* **[covers logouts]**: If `obj.type == 0`, interpret `data[0]` as a validator index as an `int64` and `data[1]` as a signature. If `BLSVerify(pubkey=validators[data[0]].pubkey, msg=hash("bye bye"), sig=data[1])`, and `validators[i].status == LOGGED_IN`, set `validators[i].status = PENDING_EXIT` and `validators[i].exit_slot = current_slot`
* **[covers `NO_DBL_VOTE`, `NO_SURROUND`, `NO_DBL_PROPOSE` slashing conditions]:** If `obj.type == 1`, interpret `data[0]` as a list of concatenated `int64` values where each value represents an index into `validators`, `data[1]` as the data being signed and `data[2]` as an aggregate signature. Interpret `data[3:6]` similarly. Verify that both signatures are valid, that the two signatures are signing distinct data, and that they are either signing the same slot number, or that one surrounds the other (ie. `source1 < source2 < target2 < target1`). Let `inds` be the list of indices in both signatures; verify that its length is at least 1. For each validator index `v` in `inds`, set their end dynasty to equal the current dynasty plus 1, and if its `status` does not equal `PENALIZED`, then:

1. Set its `exit_slot` to equal the current `slot`
2. Set its `status` to `PENALIZED`
Expand Down

0 comments on commit 0c0b7b7

Please sign in to comment.