lab1-vdikan-canvas

Demo contract: Painting pixels on a Canvas with time lock.

Deployment

Run ./build.sh located in the project root. It compiles ./out/main.wasm.

The canvas width and height are contract initialization parameters and should be set upon initial deployment, e.g.:

near dev-deploy --initFunction new --initArgs '{"width":20, "height":20}'

Contract Views

get_pixel(x: usize, y: usize)

Return the status of the pixel at (x, y): current color and if it is booked or free based on release_timestamp.

Free method.

near call @dev-account  get_pixel --args '{"x": 20, "y": 20}' --accountId @account.testnet

set_pixel(x: usize, y: usize, color: [u8, 3])

Repaint pixel at (x, y) to a new color (vector of R,G,B u8 channels), if it is not held at the time of transaction.

Payable method. Minimal deposit locks pixel for 30 seconds. All the amount above buys extra time in proportion: 50 seconds for each 1 token above.

near call @dev-account set_pixel --args '{"x": 2, "y": 1, "color": [70, 90, 31]}' --accountId @account.testnet --amount=5.5

Possible Improvements

• Storage optimization using near_sdk::collections.

  Not sure if it is worth it. Frontend will expect all the canvas data at once, therefore standard Vec<> of pixels required.

  At the same time, release_timestamps could be stored as separate array. Here Vector from near_sdk::collections may suit better.

• JSON-serizalization of view call responses.

  That is what front-end would expect.