Sprint #10 - 2019-05-03

Sprint metrics

  • Story Points: 76

  • Average Velocity: 74,85

  • Story Points for Code Freeze: 122

  • Story Points for Technical Go-live: 508

User stories

RLAU-1100 - Static sharding

Story
Criteria

A quick and dirty first version of static sharding to increase network throughput.

  • Contributor: Dan

  • Component: core

SETUP As a node runner, I want to define my shard range So that can maximize the earning potential of my node.

Scenario 1: There is a valid shard range Given ‌that I have defined a shard range, That is smaller than 2^44, and that is bigger than 0, When ‌I start the node, Then ‌the Node will start successfully.

Scenario 2: There is a invalid shard range Given ‌that I have defined a shard range, That is not a integer, or that is bigger than 2^44, or that is smaller than 0, When ‌I start the node, Then ‌the Node will give me an error.

Scenario 3: The shard range is too large for the device Given ‌that I have defined a shard range, That is too big for my device, When ‌I start the node, Then ‌the Node will never be in sync.

BROADCAST OF SHARD RANGE As a node runner, I want my peers to know the shard range that I'm serving So that they can send me relevant atoms

Scenario 1: Given ‌that I'm running a live node, When ‌join the network / periodically, Then ‌I want to include my shard range on peer discovery messages.

RECEIVAL OF SHARD RANGE As a node runner, I want my peers to be sending correct shard ranges to me, So that I can deliver relevant atoms to them.

Scenario 1: Peers are sending valid shard ranges Given ‌that I am running a node, When ‌a peer sends me a shard range, That is smaller than 2^44, and that is bigger than 0, Then ‌I will continue talking to that node.

Scenario 2: Peers are sending invalid shard ranges Given ‌that I am running a node, When ‌a peer sends me a shard range, That is not a integer, or that is bigger than 2^44, or that is smaller than 0, Then ‌I will tell the network about the fault with proof and stop talking to that node.

Scenario 3: Peers are sending valid shard ranges that are correct. Given ‌that I am running a node, When ‌a peer sends me a shard range, That is consistent with what I know about that node in my own ledger. Then ‌I will continue talking to that node.

Scenario 4: Peers are sending valid shard ranges that are false. Given ‌that I am running a node, When ‌a peer sends me a shard range, That is inconsistent with what I know about that node in my own ledger. Then ‌I will tell the network about the fault with proof and stop talking to that node.

RECEIVAL OF ATOMS As a node runner, I want my peers and clients to only be sending me atoms related to the shards I'm serving, So that I can be efficient in my processing.

Scenario 1: Peers are sending valid shard ranges Given ‌that running a node, and I have configured my shard range correctly, When ‌I receive an atom that is relevant to my shard range, Then ‌I will process it.

Scenario 2: Peers are sending me atoms that are not relevant to me Given ‌that running a node, and I have configured my shard range correctly, and that I have not just changed my shard range, When ‌I receive an atom that is not relevant to my shard range, Then ‌I will tell the network about the fault with proof and stop talking to that node and I will throw the atom away.

Scenario 3: I just changed my shard range Given ‌that running a node, and I have configured my shard range correctly, and I have just changed my shard range, When ‌I receive an atom that is not relevant to my shard range, Then ‌I will not tell the network about the fault with proof and not stop talking to that node, but I will throw the atom away.

Scenario 4: Clients are sending me atoms that are not relevant to me Given ‌that running a node, and I have configured my shard range correctly, and that I have not just changed my shard range, When ‌I receive an atom that is not relevant to my shard range from a client, Then ‌I will throw the atom away.

SENDING OF ATOMS As a node runner when I receive a new valid atom, I want to gossip that atom to other nodes that serve its shards, So that they can process the atom and discover any conflics that I'm not aware of.

Scenario 1: I send an atom to a node I know Given ‌that I'm running a live node and have valitaded an atom, and I know at least one node from each of the atom's shards, and I can send it to at least two, Then ‌I will broadcast it to them.

Scenario 2: I don't know any node on that shard Given ‌that running a live node, and have valitaded an atom, When ‌I receive an atom that uses a shard that I don't know of any nodes that serve that shard, Then ‌I can process it and share it with someone else - random, and I don't fucking know!

Scenario 3: I'm at the end of the gossip Given ‌that I'm running a live node and have valitaded an atom, and I am at the end of the gossip tree, Then ‌I will not broadcast it.

Scenario 4: I can't send the atom to the nodes Given ‌that I'm running a live node and have valitaded an atom, and I get disconnected from the network, Then ‌I will broadcast it with best effort.

RLAU-1107 - Initial flow foundation with simple UI interface

Story
Criteria

Built a simple UI and workflow for the Android payment card app demo.

  • Contributor: Marc

  • Component: payment card demo

User story As a wallet user, I want to see a User Interface with all necessary features, so that I can get setup and transact with the network securely.

Scenario: Create a barebone skeleton with minimal design flow project

Given keynote design When app is used Then I can navigate through all screens and states in a fake way with barebones design

RLAU-1108 - Change simple UI to actual UI that will be used

Story
Criteria

Develop a generic UI where clients can easily skin and choose their own colour schemes and add logos.

  • Contributor: Marc

  • Component: payment card demo

Scenario: Change barebones/minimal design to actual design from keynote, recreate to resemble as close as possible

Given keynote design When app is used Then design with colours, style etc should ressemble it as close as possible.

RLAU-1109 - Hook actual UI with logic to be used with radixdlt-java library + NFC communication

Story
Criteria

Connected the radixdlt-java lib at every needed point such as: creating an identity, building atom, submitting atoms.

  • Contributor: Marc

  • Component: payment card demo

Scenario: Using app with library

Given POS app is making use of the library When using the app Then a radix identity is created which can interact with the network

Scenario: User first tap of card, unsigned atoms is built

Given POS app requests tap When user first taps Then public key is read and an unsigned atoms is created.

Scenario: User first tap of card, unsigned atoms is built but insufficient funds

Given POS app requests tap When user first taps Then public key is read and an unsigned atoms is created but insufficient funds so user is informed

Scenario: User second tap of card correct pin

Given user has typed correct pin When user taps a second time Then signed atom is received and is submitted to the network

Scenario: User second tap of card incorrect pin

Given user has typed an incorrect pin When user taps a second time Then error is received from card, user requested to type pin again

RLAU-1190 - Initial first time setup screens with master pin

Story
Criteria

Built an initial setup workflow with master pin. After the setup, any important information can only be modified by authorised personel by using the master pin.

  • Contributor: Marc

  • Component: payment card demo

Scenario: First time setup screens where master pin is selected and securely saved

Given POS app is launched for the first time When when user navigates through the flow Then a master pin is selected and securely saved

Scenario: First time setup screens where invoice name is selected and saved

Given POS app is launched for the first time When when user navigates through the flow Then an invoice/company name is selected and saved

Scenario: First time setup screens where address selected and saved

Given POS app is launched for the first time When when user navigates through the flow Then an address where transactions are going to be sent can be set and saved

Scenario: First time setup screens where address can be scanned from camera via qr and saved

Given POS app is launched for the first time When when user navigates through the flow Then an address where transactions are going to be sent can be scanned with the camera and saved

Scenario: First time setup screens where address can be scanned from camera via qr and saved

Given POS app is launched for the first time When when user navigates through the flow Then an address where transactions are going to be sent can be scanned with the camera but not correct address format hence user is informed and not allowed to progress