Completed: ICDevs.org Bounty #21 - QuickStart - Actor Model - 200, 100, 50 ICP Prizes

Developers Bounties
1

Our first QuickStart bounty has produced four sample dapps so far. You can see the entries below. We are also excited to announce our second QuickStart bounty:

CB-elite - key value store - https://forum.dfinity.org/t/icdevs-org-bounty-20-quickstart-dapp-scaling-with-canisters-200-icp-100-icp-50-icp-multiple-winners/11756/23?u=skilesare

Iceypee - shared canisters - https://forum.dfinity.org/t/icdevs-org-bounty-20-quickstart-dapp-scaling-with-canisters-200-icp-100-icp-50-icp-multiple-winners/11756/19?u=skilesare

GLdev - storage and indexing across container - Complete: ICDevs.org Bounty #20 - QuickStart Dapp - Scaling With Canisters - 200 ICP, 100 ICP, 50 ICP - Multiple winners - #15 by GLdev

Hoosan - auto scaling node - Complete: ICDevs.org Bounty #20 - QuickStart Dapp - Scaling With Canisters - 200 ICP, 100 ICP, 50 ICP - Multiple winners - #10 by hoosan

QuickStart Dapp - Scaling With Actors - #21

Current Status: Discussion

  • Open for submission - (04/26/2022)

  • Closed

Permenant Link

Bounty Details

  • Bounty Amount: 200 ICP First Prize, 100 ICP Second Prize, 50 ICP Third Prize

  • Project Type: Single Contributor/Team

  • Opened: 04/26/2022

  • Time Commitment: Weeks

  • Project Type: Sample App

  • Experience Type: Intermediate - Motoko; Intermediate - Rust; Intermediate - Web

Description

This bounty gives the opportunity to

  • learn motoko

  • learn rust

  • learn how scaling works

  • learn how to use canisters to create canisters

  • learn about the actor model

  • learn how clients access the Internet Computer

The goal of this bounty is to produce a sample application on the Internet Computer.

Goal: Demonstrate the actor model on the internet computer using a multi-canister architecture

Create a practical dapp that demonstrates the actor model of programming such that a system produces “actor” canisters that can interact in a meaningful and productive manner.

Reach goal 1: Create a system of trust such that all crated actors can inherently trust each other.

Reach goal 2: Create a multi-tenant system that supports multiple actors on one canister to reduce costs, but can “spin out” the actor once it reaches a certain size/value.

Example A: Create a token that has no ledger but trades value between trusted actors such that no tokens can be created or destroyed.

Example B: Create a social application where each “space” can be spun out to its own canister once it has been vetted by the community.

Example C: Create a defi marketplace that spins out a new actor for each asset traded such that all functions of the marketplace are contained inside the actor.

Your application can be written in either motoko, rust, or azel. Further, a motoko and rust version can be submitted as separate entries by the same person/team.

The code must be opensourced using the MIT License.

To submit for this bounty you should:

Create a github repo with your sample application and post the link to either the (dev forum post) or the (ICDevs.org dscvr portal)[DSCVR].

We will start selecting prize winners by May 12th, 2022. Submission will stay open until we believe we have a sufficient number of sample applications. Multiple prizes may be awarded for submissions that reach a sufficient level of completeness.

Bounty Completion

Once your app is complete and submitted, it will be judged on the following criteria:

  • How relevant is this sample dapp for the community?

  • How well is the sample dapp’s functionality presented?

  • Does this sample dapp help me to build enough? Can I use the sample dapp for a real project?

  • How well was the sample dapp written?

  • How many goals were reached?

Bonus considerations:

  • Are there tests?

  • Is the documentation provided (readme file on github) sufficient?

  • A user interface of some kind is highly encouraged so that users of your sample application can get a visual view of how your application works.

Funding

The bounty was generously funded by the DFINITY Foundation. Additional donations that fund the administration of these bounties can be sent to ICDevs.org. All donations will be tax deductible for US Citizens and Corporations. If you send a donation and need a donation receipt, please email the hash of your donation transaction, physical address, and name to donations@icdevs.org. More information about how you can contribute can be found at our donations page.

Other ICDevs.org Bounties

2

Can I ask for a clarification of the second goal or some kind of example of:
Create a multi-tenant system that supports multiple actors on one canister to reduce costs, but can “spin out” the actor once it reaches a certain size/value.

Isn’t each canister only able to hold one actor? And if you mean like a middleman/state canister that keeps a list of actor classes and keeps track and manages the actors (not considering the middleman as an actor here); do you mean when the middleman canister runs out of space it scales itself or do you mean it watches for the actors and if they run out of space, it automatically creates an extension of that actor?

I guess to follow up, for a canister holding multiple actors in a list, do you know if it actually hold the actor (so it’s storage is equal to all the actors storage it holds) or are they just references? I did a test by checking statuses of the actors and it seems like the storage space doesnt add the entire storage of a created actor but just wondering if anyone knows for certain.

1 Like
3

I think this may be as easy as having the actor capable of holding assets/info for multiple entities in a triemap [principal, data] and having an authorized list where functions check the caller. When the canister gets too big it ejects a principal into their own canister with only their principal authorized on the canister, but all the rest of the code the same. It is a bit of mix of actor model and scaling with canisters. It isn’t required for the challenge, but a reach goal!

2 Likes
4

Ah I see, thank you!

5

Hey everyone, here’s my entry for this QuickStart. It got delayed a bunch with all the prep work for the hackathon, but I managed to bring it to a point where it might be useful for someone.

Brief project description: In this example, we are playing with colonies and spawning new canisters for “remote colonies”. Each colony has three main modules - work, expeditions and customs office (travel).

In a normal flow, the user joins the main colony and starts working. Each colony issues x amount of resources per second. When the user stops working the resources get credited to their inventory. Expeditions can be started by anyone that has the required number of resources. Once an expedition is proposed it goes through a number of steps, ending in the spawning of a new canister and the creation of a new colony. The spawned canister is a “clone” of the main canister, with some settings changed (e.g. generation++, resources+++, etc.)
There is some code to handle the customs office (each colony taxes the inventories of every “incoming” player), but I haven’t finished this in the frontend, so it’s not included in this demo. The unit tests are there if anyone wants to give it a try.

Tech concepts I wanted to explore:

  1. The main difference from the scalability QuickStart is that this project does not use the heartbeat. Every interaction is powered by update calls from clients.
  2. Things are computed on interaction (e.g. the inventory is credited only on stop_work, and the computation is done “server side”).
  3. In true actor model, the canister is a true replica of itself. This gave me the opportunity to explore loading the wasm file via a helper binary. If you wanted to programmatically call canisters from rust, there’s a quick example.
  4. For moving expeditions along I used a “state machine” approach, that I find pretty easy to reason about:
pub enum ExpeditionStep {
    /// This is the default state of an expedition. In this state we wait until the conditions
    /// are met. Players can join the expedition in this step.
    Proposed,
    /// This state indicates tha the conditions for the expedition have been met, and we are ready to
    /// start the expedition. Players cannot join the expedition at this point.
    Ready,
    /// The async process of starting a new expedition has started at "timestamp". We can later implement
    /// some retry logic based on the timestamp.
    Starting(TimestampMillis),
    /// The new expedition was started, a new world has been spawned and we got confirmation that
    /// the new world is ready.
    Started(Principal),
    /// The end of an expedition's lifecycle. We can hold on to the expedition as a log of sorts
    /// but for all intents and purposes this is a finished task.
    Done,
}

The “expeditionNextStep” function can be called by anyone (even anonymous) as all the logic is handled server side. I find this to be preferable and by having more intermediary steps, we are protected from entire classes of attack (e.g. double spend, race conditions). Each state can only lead to the next, and once the conditions are met, it is changed and the next “threads” simply get ignored.
5. I like the pattern of the last unittest in src/lib.rs, check it out. It forces you to manually review your did interface, while also alerting you if the code has changed in reality. Pretty neat pattern.

I missed last week’s ICdevs call, and I’ll not be available tomorrow on the 1’st, but I’ll be around discord and the forum if people have questions. In general this was a pretty straight forward exploration of concepts, but I did find it pretty tedious to code game logic from scratch. I really hope someone is tackling the game-dev problem, perhaps with an ECS-type thing on the IC. We could use such an effort!

You can find the repo here

And a demo video here

2 Likes
6

I love it! Very cool.

7

How about iCAN ?
iCAN is a Canister Management Platform in IC ecosystem
Support Many features:

  1. Log System(Use Stable Memory Bucket Lib)
  2. Creating Canisters in random subnet (iCAN canister creates Hub canisters in random subnet)
  3. Hub Canister creates canisteres (Scaling with actors )

Source Code: GitHub - PrimLabs/iCAN: iCAN : Canister Management Tool
app link : icantool.app
More Tech Details : iCAN: The Best Easy-to-use Canister Management Platform — MixDAO

8

Hey, I created an actor model project called bitcoin federal reserve. Essentially, you send bitcoin in storage canisters to another canister and you mint individual cash tokens that are not ledger based but individual canisters themselves (to fit the actor model bounty). I sent this summary below not too long ago to Austin on Discord but so everyone can see it now that the project is open: →

The actor model comes in two parts. Essentially, I created a canister that can make multiple bitcoin canisters (unsafely generating private keys and depositing it in an container actor class) for anyone to store bitcoin and that container becomes a single actor that can be transferred. I then have a bank canister that allows people to deposit their bitcoin stores which then mints a token 1:10000 per satoshi. This is where the second actor model usage comes in. I dont just mint an erc20 like on eth with a ledger. Instead I generate canisters that are representitive of a single token which holds the owner’s principal inside a private var.
Some use cases:

  1. allow people to give an in game currency value right off the bat, by backing a token one to one, and the people that store their bitcoin can earn from in game transactions or something.
  2. simulate how the usa federal reserve should have worked when we used the gold standard although it didnt
  3. Allow users to make less traceable bitcoin peg. Assuming dfinity does work with their secure enclave thingy they talked about in the forum, (dont know much about it but its supposed to prevent nodes from peaking into canister statuses and transactions,) , this should people to deposit bitcoin for a less traceable version thats pegged 1:1 with the amount they deposited

Below are the links to a video description of how it works (1st one) and (2nd one) me actually running it, (3rd one) The Github… I will do my best to update the README slowly. Right now, its just the default btc-integration README on the github front page, but I will modify it whenever here and there between work and home life.
Looking forward to feedbak.

4 Likes
9

C-B-Elite — Sorry for the delay on this…did you intend this to be a submission or was this just something you did elsewhere? It looks like a meta-tool to help implement the actor model(very cool) but I’m not sure it fits the challenge. Please ping me and let me know the story here.

1 Like
10

Sorry for the delay here…Supernova and then a bunch of releases, etc. It shouldn’t have taken this long. We are awarding @Iceypee and @GLdev First Prize for their entries here.

And as an added bonus, Going back to QuickStart one we are retroactively doubling the bounties due to the price drop! I’ll be reaching out to the previous winners in a bit. Congrats all!

Also, please let me know if you are interested in talking more formally about your applications and what makes them special.

1 Like
11

I wanted to again thank Austin, and Dfinity for taking care of the developers! Going back and adjusting for market trends is a great way to keep the people engaged and interested in contributing! This is the way!

12

Hey bounty winners @C-B-Elite, @Iceypee, @GLdev, and @Hoosan

since Internet Computer Home | Internet Computer Home is now open for community contributions, I’d like to invite you to create a PR to include your work.

4 Likes