datalogiforalle / blockchain-sim Goto Github PK

Både i den nuværende Django-implementering og i den oprindelige Flask-app, kan forskellige blokke tilhørende samme blokkæde få samme blok-ID. Dette kan sker, hvis to brugere tilføjer blokke i forlængelse af samme blok.

Er det meningen, eller er det noget, som skal fikses?

• For meget white space (margen) over page_headeren?
• For lidt vertikalt whitespace mellem andre elementer på siden?

Eventuelt flere sværhedsgrader
Nemt: starter med 0, 1 eller 2
Middel: starter med 0
Svær: starter med 00

https://www.w3schools.com/howto/howto_css_loader.asp

Skal hash af genesis-blokken altid være '0' uanset sværhedsgrad?
Prev_hash af block #1 lever pr kontruktion ikke op til kravene til blokkæden... er dette et problem?

What to do?

• I "Django for professionals" er der et kapitel med forskellige strategier for at optimere en Django-applikation.
• Herudover ville det måske være en ide at skifte database fra sqlite til postgresql

This view function is too long and hard to understand. Consider:

• Making separate view-functions for post-requests
• Making a class-based (base-)view instead (def get(), def post(), def _helper_method() ...
• Perhaps use decorator to pass arguments to view functions: https://stackoverflow.com/questions/1965607/how-can-i-pass-a-variable-in-a-decorator-to-functions-argument-in-a-decorated-f

I givet fald: Hvad er det præcis for et tidspunkt, der menes?

I den oprindelige flask-applikation er det tvetydigt, hvad der menes med en bloks skabelsestidspunkt. I formen, som hashet beregnes på baggrund er, er created_at et tidspunkt, hvor brugerens session data senest er blevet opdateres. Men hvis brugeren gemmer en blok på databasen, så er created_at = 'current timestamp'. Dette betyder, at der gemmes blokke med ugyldige hashes i databasen.

I den oprindelige flask-app ville alle blok-elementer med blok-id=0 (altså start-blokken i hver kæde) have præcis samme hash, hvis skabelsestidspunktet ikke indgik i beregningen af hash-værdien. I den nuværende Django-app indgår skabelsestidspunktet ikke. I stedet har jeg tilføjet bruger-id'et for den, der skaber den nye blokkæde, til beregningen af hash-værdien for blok-0. På den måde får man forskellige start-hashes for hver ny kæde, selvom tidspunktet ikke indgår.

Vi bruger farver som kendetegn for minearbejdere. Det kan derfor forstyrre lidt, at vi også bruger bootstrap-farver til knapper og meddelelser (orange for" warning", fx). Overvej at minimere brugen af farver til at signalere andet end minearbejder-identitet. Lav knapper grå. Skriv meddelelser i sort/hvid? Det skal nok lige afprøves, hvordan dette fungerer i praksis.

Using the same form-object several times is a bad idea.

Hver deltager i blokken har sin egen farve - deltagernavn og blokke lavet af denne deltager skal vises i denne farve.

Værdien af disse konstanter betyder ret meget for spiloplevelsen. Det vil dog kræve afprøvning på større grupper elever, før man kan finde gode værdier, tror jeg:

MINER_REWARD = 100
BANK_TOKEN_PRICE = 150
NUM_INITIAL_TRANSACTIONS_PR_MINER = 2
NUM_TOKENS_FOR_SALE_IN_BANK_AT_ALL_TIMES = 3
ADD_TO_CHAIN_TIME_DELAY_IN_SECONDS = 2

Derudover bør der måske være flere hash-sværhedsgrader. Og så bør der måske være en vejledning med anbefalet sværhedsgrad givet et bestemt antal minearbejdere.

Sørg for at alle farver er relativt lyse?