Giter VIP home page Giter VIP logo

education-cryptomoji's Issues

Client: Allow users to "signup/login" with a private key

Users should be able to generate a new private key, which will be analogous to a username/password. Generated private keys should be copyable and/or downloadable. Generating a private key should automatically create a collection and "log in" to the app.

Alternatively, users should be paste in an private key to "log in" with an existing Collection. If this private key has no Collection, one should be generated (possibly after some sort of confirmation that it isn't a typo).

Video: Blockchain

Blocked by #60

Use the blockchain script and slides to record a video lecture for General Blockchain information.

Script/slides: General Blockchain

Generate a script and slides educating students on general blockchain knowledge. Should more or less follow this structure:

  • Birds eye view
    • What is it?
    • What is it good for?
  • Blockchain data structure (i.e. blocks linked by hashes)
    • How does hashing work?
    • SHA-512 (briefy)
    • SHA-512 hashes in Node
  • Transactions (i.e. signed payload, atomic unit of change)
    • What is a private/public key pair?
    • What is a signature?
    • Secp256k1 (briefly)
  • Consensus (briefly)
    • PoW, PoET, and something non-BFT
    • Crash Fault Tolerance vs Byzantine Fault Tolerance
  • Part-One Project
    • Basic instructions

TP: Implement SELECT_SIRE action

Include tests to demonstrate it is working. Blocked by #10.

Original Design

Selects a cryptomoji as a collection’s sire, making it available for breeding.

Requirements

  • Signer must be registered as a collection
  • Signer must own cryptomoji
  • Cryptomoji must exist
  • Cryptomoji must not be a part of any Offers
  • Cryptomoji must not be currently incubating

Payload Schema

{
  "action": "SELECT_SIRE",
  "sire": <string, address>
}

State Schema

{
  "owner": <string, public key>
  "sire": <string, address>
}

State Address

The final 62 characters of a Sire Listing’s address are the first 62 characters of a SHA-512 hash of the owner’s public key.

5f4d76 04 1b96dbb5322e410816dd41d93571801e751a4f0cc455d8bd58f5f8ad3d67cb
  -> 
{
  "owner":
    "034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa",
  ...
}

Video: Cryptomoji

Blocked by #62

Use the Cryptomoji script and slides to record a (short) video lecture explaining the Cryptomoji project.

TP: Build "Hello World" transaction processor

An initial version of the transaction processor that can register with the Sawtooth Validator, and receive and correctly handle a CREATE_COLLECTION action. Should also include unit tests to confirm it works properly. Blocked by #9.

Original Design

Essentially just used to register a public key in the app. Creates a new collection with the transaction signer’s public key and an empty set of cryptomoji.

Requirements

  • Signer’s public key must not already be registered

Payload Schema

{
  "action": "CREATE_COLLECTION"
}

State Schema

{
  "key": <string, public key>,
  "moji": [ <strings, addresses> ]
}

State Addressing

Namespace

The first six characters are reserved for an application namespace. In this case, we will use the first six characters of a SHA-512 hash of the application name, “cryptomoji”.

5f4d76

Resource Prefix

Next a one byte (two character) prefix follows which designates what sort of resource will follow:

  • 00: BlockInfo
  • 01: Collections
  • 02: Collection Resources (i.e cryptomoji and offers)
  • 03: Sire Listings

Collection Hash

The final 62 characters of a collection’s address are the first 62 characters of a SHA-512 hash of the public key.

5f4d76 01 1b96dbb5322e410816dd41d93571801e751a4f0cc455d8bd58f5f8ad3d67cb
  -> 
{ 
  "key":
    "034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa",
  ...
}

Finalize Part-One

  • Review and flesh out all docstrings
  • Ensure test coverage is adaquate
  • Add problemify-style solution/problem comments for splitting staging code into stub and solution code

Design Cryptomoji DNA

Come up with a way to generate random DNA strings and render those as kaomoji. These strings ideally should be able to represent every existing kaomoji, and should only generate weird garbage 10% of the time or so. Bonus points if it can come up with novel kaomoji.

In addition to generating from scratch, there needs to be a process for combining to DNA strings into something derivative of both, and still slightly random.

Remember Math.random() can NOT be used here. Pseudo-random elements should appear random, but must be generated deterministically based on transaction, batch, or block info, or current blockchain state.

TP: Implement BlockInfo transaction injection

Use Sawtooth's batch injector API (https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/injecting_batches_block_validation_rules.html), to inject initial Block Info entities. For the first pass they should just be a timestamp and block number, no new cryptomoji generated. Include tests to demonstrate it is working. Blocked by #9.

Original Design

This payload would be sent to the TP by the publisher themselves. It should never be sent by the client. The TP would handle generating the new gen 0 cryptomoji, and selecting a pseudo-random (but deterministic) collection to give it to.

Requirements

  • Signer must be the block publisher

Payload Schema

{
  "action": "ADD_BLOCK_INFO",
  "timestamp": <int>
}

State Schema

{
  "blockNumber": <int>,
  "winner": <string, public key>,
  "timestamp": <int>
}

State Address

Namespace

The first six characters are reserved for an application namespace. In this case, we will use the first six characters of a SHA-512 hash of the application name, “cryptomoji”.

5f4d76

Resource Prefix

Next a one byte (two character) prefix follows which designates what sort of resource will follow:

  • 00: BlockInfo
  • 01: Collections
  • 02: Collection Resources (i.e cryptomoji and offers)
  • 03: Sire Listings

Block Number

The remaining 62 characters of a Block Info address is simply the hexadecimal representation of their block number.

5f4d76 00 000000000000000000000000000000000000000000000000000000000000a7
  -> { "blockNumber": 167 ... }

Client: Create module to make API requests

Getting state information from the Sawtooth REST API will be non-trivial, and should be encapsulated in one or more modules.

First, it should be able to make a /state request specific to one type of resource, or one particular resource. Pages using this module should have no knowledge of how addressing works. They would only have to specify resource type and (if applicable) identifier.

Second, it must be able to decode the bytes information that comes back into JavaScript objects or arrays. Pages using this module should have no knowledge of the encoding scheme used for on-chain data.

Finally, it must be able to encode and submit transactions, including waiting on the results to be committed, and fetching those results.

The rest of the client app should be able to use this module with the same level of abstraction as they would a typical REST API, but with function calls instead of HTTP requests.

TP: Implement CREATE_OFFER action

Include tests to demonstrate it is working. Blocked by #12.

Original Design

Creates a new offer to trade away a set of cryptomoji.

Requirements

  • Signer must be registered as a collection
  • Signer must own the offered cryptomoji
  • Offered cryptomoji must exist
  • Offered cryptomoji must not be currently listed as a sire

Payload Schema

{
  "action": "CREATE_OFFER"
  "moji": [ <strings, addresses> ]
}

State Schema

{
  "owner": <string, public key>,
  "moji": [ <strings, addresses> ],
  "responses": [
    {
      "owner": <string, public key>,
      "moji": [ <strings, addresses> ],
      "isRequest": <bool>
    }
  ]
}

State Address

The final 52 characters of an Offer’s address is the first 52 characters of a SHA-512 hash of the concatted addresses of the cryptomoji being offered.

5f4d76 02 1b96dbb5 01 f365bcdd7f317faeebc49daf2cc7a3f5bf169a19010197c51f32
  -> 
{
  "moji": [
    "5f4d76011b96dbb502f365bcdd7f317faeebc49daf2cc7a3f5bf169a19010197c51f32"
  ]
  ...
}

TP: Add CANCEL_RESPONSE action

The signer who created a response should be able to cancel it. Canceled responses should become null to avoid changing their index.

TP: Implement ADD_RESPONSE action

Include tests to demonstrate it works. Blocked by #17.

Original Design

Adds a response to an Offer.

Requirements

  • Signer must be registered as a collection
  • Signer must own the cryptomoji or be the owner of the Offer
  • All cryptomoji must exist

Payload Schema

{
  "action": "ADD_RESPONSE",
  "offer": <string, address>,
  "moji": [ <strings, addresses> ]
}

State Schema

{
  "owner": <string, public key>,
  "moji": [ <strings, addresses> ],
  "responses": [
    {
      "owner": <string, public key>,
      "moji": [ <strings, addresses> ],
      "isRequest": <bool>
    }
  ]
}

Build docker-compose framework

Build a docker-compose framework to build and run the validator, REST API, transaction processor, and server the client.

TP: Track offer/response involvement on each moji

Each moji needs an offers array with the address of each offer they are listed in, either as one of the offer moji, or in one of the responses.

This should then be used to add some extra verification:

  • You cannot select sires in an offer/response you initiated
  • If your new sire is in a response someone else initiated, that response should be nulled
  • When moji are traded any offers or responses they are a part of should get removed or nulled.

TP: Implement ACCEPT_RESPONSE action

Include tests to demonstrate it works. Blocked by #19.

Original Design

Closes an Offer and exchanges the cryptomoji in the Offer body and specified response.

Requirements

  • Signer must be registered as a collection
  • If the specified response is not a request, the signer must own offer
  • If the specified response is a request, the signer must be the owner in the response
  • The cryptomoji exchanged must all still be owned by the appropriate parties
  • The response index must correspond to a valid response on the offer

Payload Schema

{
  "action": "ACCEPT_RESPONSE",
  "offer": <string, address>,
  "index": <int>
}

Write READMEs

Add README files to:

  • the root directory
  • code/part-one
  • code/part-two
  • code/part-two/client
  • code/part-two/processor

These READMEs should include:

  • guidance about how to use the repo
  • instructions on how to start components
  • instructions on how to run tests and complete problems
  • design specs for the apps being built

Design/Create initial repo structure

Add the initial directories necessary to hold all learning materials, intro App (final) code, Cryptomoji app (final) code. Consult past HR sprints for guidance.

This task will be "Under Review" in PR form. Once approved by the group and merged, it will be done.

TP: Implement BREED_MOJI action

Include tests to demonstrate it is working. Blocked by #15.

Original Design

Spawns a new cryptomoji for the collection after an incubation period.

Requirements

  • Signer must be registered as a collection
  • Signer must own breeder
  • Sire must be listed as a Sire
  • Cryptomoji must exist
  • Cryptomoji must not be a part of any Offers
  • Breeder must not be currently incubating

Payload Schema

{
  "action": "BREED_MOJI",
  "sire": <string, address>
  "breeder": <string, address>
}

State Schema

{
  "dna": <string>,
  "generation": <int>,
  "collection": <string, id>,
  "sire": <string, id>,
  "breeder": <string, id>,
  "sired": [ <strings, ids> ],
  "bred": [ <strings, ids> ],
  "lastSired": <int, block number>,
  "lastBred": <int, bock number>
}

State Address

The final 52 characters of a cryptomoji’s address is the first 52 characters of a SHA-512 hash of their DNA string.

5f4d76 02 1b96dbb5 00 d1dd9beeb54338f0650588247d5b14af9609a59a9df42a61cfa7
  -> { "dna": "aWFtZG5h" ... }

Client: Allow users to select/view sires

Users should be able to select one of their cryptomoji as a sire, available for breeding.

They should be able to view the available sires.

They should be able to select a sire and one of their own cryptomoji and breed them. (Moved to #68.)

Finalize Part-Two

  • Review and flesh out all docstrings
  • Ensure test coverage is adaquate
  • Add problemify-style solution/problem comments for splitting staging code into stub and solution code

TP: Expand BlockInfo with cryptomoji generator.

Generate new cryptomoji on BlockInfo transactions. Make sure the module that generates them is either comprehensive (generates every possible kaomoji ever), or easily expandable. Include tests to demonstrate it is working. Intrinsically tied to #13 , as the DNA generated must be renderable by the client, not just a random string. Blocked by #11, and #14.

Original Design

This payload would be sent to the TP by the publisher themselves. It should never be sent by the client. The TP would handle generating the new gen 0 cryptomoji, and selecting a pseudo-random (but deterministic) collection to give it to.

Requirements

  • Signer must be the block publisher

Payload Schema

{
  "action": "ADD_BLOCK_INFO",
  "timestamp": <int>
}

State Schema

{
  "blockNumber": <int>,
  "winner": <string, public key>,
  "timestamp": <int>
}

Script/slides: Cryptomoji project

Generate a brief script and slides to prime students for part-two, Cryptomoji. Should include the data model and specs students are expected to implement, more or less following this structure:

  • Cryptokitties
    • What was it?
    • Why was it interesting?
  • The data model, state addressing, and API specs
    • CREATE_COLLECTION
    • SELECT_SIRE
    • BREED_MOJI
  • Extra Credit
    • Deleting state
    • Additional specs
      • CREATE_OFFER
      • ADD_RESPONSE
      • ACCEPT_RESPONSE
      • CANCEL_OFFER
      • CANCEL_RESPONSE
  • Nightmare Mode
    • Settings family
    • Batch Info family
    • Additional Specs
      • Add incubation times to sires and breeders
      • Randomly assign cryptomoji each block instead of at collection creation

Add Tests for Intro App

These tests will be what students will code against, and should be comprehensive and well explained.

TP: Implement CANCEL_OFFER action

Include tests that demonstrate it is working. Blocked by #17.

Original Design

Deletes an existing Offer without exchanging any cryptomoji.

Requirements

  • Signer must be registered as a collection
  • Signer must be the owner of the Offer
  • Offer must exist

Payload Schema

{
  "action": "CANCEL_OFFER"
  "offer": <string, address>
}

Client: Add requests tests

Requests module should be standardized with tests. Requires pulling in superaget and doing some mocking.

Client: Build "hello world"

Using React, or whichever tool would be most appropriate to the HR curriculum, build a basic web app. Should include whatever components will be needed (router, state, etc), with placeholder content.

Video: Sawtooth

Blocked by #61

Use the Sawtooth script and slides to record a video lecture.

TP: Refactor moji to be independent of collections

The use of addresses as ids, and the use of a collection prefix in that address, makes it impossible to properly track the family tree of a moji once trading is introduced. Cryptomoji need unique ids that do not change when they are traded.

The uniqueness of the ids must also prevent siblings with identical dna from conflicting.

Script/slides: Sawtooth Development

Generate a script and slides educating students on Sawtooth application development. Should more or less follow this structure:

  • Birds eye view
    • What is it?
    • What is it good for?
    • Permissioned blockchains
  • Running components with Docker
  • The Transaction Processor Model
    • State, Addresses, and the Merkle Tree
    • Payload/State Encoding
      • JSON (sorted, determinism!) and Buffers
    • Validation
      • InvalidTransaction error
  • Clients
    • Transaction and Batches
      • Structure
      • Generating private/public keys
      • Signing
    • The REST API
      • Submitting batches
      • Fetching state data
        • Decoding addresses and state

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.