Enumeratable accounts

[gavofyork]

Based on #192
Closes #185 , closes #209

Makes all accounts enumerable. Introduces a short-hand form for encoding addresses and the notion of an existential deposit which is the minimum amount that must be held in an account for it to be considered "alive"; if the (free) balance ever falls below this, the account is deleted. It also introduces fees for account creation, contract-creation, transfer and a rebate for account-creation with a valid or non-existent hint.

Note: This will change the Polkadot binary extrinsic format. Before it was:

[ account-id (32-bytes), index (4-bytes), call (dynamic-length), signature on first three fields (64 bytes) ]

Now, it is:

[ address (1/3/5/9/33-bytes, dependent on first byte), index (4-bytes), call (dynamic-length), signature on *original* fields (64 bytes) ]

Note that the "original fields" refer to the [ account-id (32-bytes), index (4-bytes), call (dynamic-length) ] serialisation, not the first three fields of this extrinsic.

The specific format for the new address type is one of 5 sub-formats, switched on the first byte:

• 0xff, 32-byte account id
• 0xfe, 8-byte account index
• 0xfd, 4-byte account index
• 0xfc, 2-byte account index
• [0xf0...0xfb] (invalid, reserved for future use)
• [0x00...0xef] 1-byte account index (less than 0xf0)

The account index variants are significantly smaller but require a lookup in the state. To avoid a transaction replay attack when an index changes its account, the signature is signed not with the first field as the index, but rather as the account id, thereby invalidating all previous signatures once the index is used to lookup a different id.

In addition to the sender field, any parameters to Call/Propose (PrivCall) fields that were AccountId (32-bytes) are now Address (1/3/5/9/33-bytes).

There is currently a small "easter egg" which allows an index to be reclaimed after the account to which it refers expires. The reason it's done this way rather than an explicit new dispatch call is to allow for incidental account creation (e.g. a smart contract doing the creating, or being created) to also be able to make claims.

Still todo:

• Basic implementation
• Lookup call to convert to AccountIndex from AccountId

Be hygienic:

• Disallow existence of accounts with value below existential_deposit and their indexes
• Allow reusing dead index values...
• ...for a lower tx fee

Utilise indexes:

• Introduce enum Address { Id(AccountId), Index(AccountIndex) } (this could be more efficient since AccountId could account for all AccountIndex values within its dead state)
• Efficient serialisation of Address (either 33 bytes or 1-8 bytes)
• Switch out AccountId for Address for extrinsic's sender
• Substitute AccountId for Address for extrinsic params

And of course...

• More tests around account reclaiming, particularly FreeBalance and ReservedBalance interplay
• Integrate other balance transformations into the new model
• Finalise semantics for ReservedBalance
• Useful runtime hooks for the transaction pool
• Reserve some extra initial bytes of address for future format changes
• Test for when nonce gets reset
• Updated transaction pool

[rphmeier]

should it not check if the balance < existential deposit and call on_free_too_low?

[gavofyork]

no; FreeBalance can never be >0 && <ExistentialDeposit, so if it's ripe for deletion, FreeBalance will already have been collapsed to zero.

[rphmeier]

this whole if/else could be set.get(i).map(|x| x.clone())

would be cheaper also since it doesn't need to swap

[gavofyork]

but it would clone; swap_remove doesn't.

[rphmeier]

swap_remove is more expensive as long as AccountId is Copy.

[rphmeier]

.is_zero() or < existential deposit?

[gavofyork]

VotingBalance should not be compared directly to ExistentialDeposit. VotingBalance == FreeBalance + ReservedBalance, neither of which may ever be allowed to be set s.t. >0 && <ExistentialDeposit. By extension, VotingBalance is never < ExistentialDeposit, so .is_zero() works fine.

[rphmeier]

comment is wrong (this is fn set_free_balance)

[rphmeier]

swap_remove is more expensive as long as AccountId is Copy.

[rphmeier]

if this overflows it could cause issues

[rphmeier]

or here

[tomusdrw]

We have 2 places were we submit runtime::UncheckedExtrinsic directly, so we don't have to go through serialization:

polkadot/service/src/lib.rs
131:			match self.pool.import_unchecked_extrinsic(uxt) {

polkadot/consensus/src/lib.rs
552:			self.transaction_pool.import_unchecked_extrinsic(uxt)

[gavofyork]

the implementation shows it's just a shim for the underlying pool's api:

self.inner.submit(vec![uxt]).map(|mut v| v.swap_remove(0))

if it's really just meant to be a convenience method for submitting a single transaction then fair enough, but in that case it should be named submit_typed or some such. "import" suggests it uses different logic to "submit" which (aside from the largely superficial typing) it doesn't.

[rphmeier]

LGTM modulo sync tests being ignored