effectai / effect-network Goto Github PK
View Code? Open in Web Editor NEWSmart contracts and documentation for Effect Network
License: MIT License
Smart contracts and documentation for Effect Network
License: MIT License
It should be possible to create campaign with 0 rewards.
At the moment this is not possible (there is a silent failure in the UI, with an error printed to the console related to "transfer positive quantity)"
This is most likely because the smart contract tries to send a 10% fee (which amounts to 0). The fee should be skipped for free campaigns.
Enable posting of proofs to proposals that indicate that the author has finished the implementation.
At the moment the final state of an accepted proposal is to be executed, which means the funding payment has been made by the DAO. There is no way to communicate on-chain that a proposal has been finished by the author.
Being able to proof finalizing a proposal on-chain is useful for several reasons:
Automate the processing of a finished cycle in 1 action, including the creation of a new cycle, execution of recycle strategy, and vote counting.
Rounding up a cycle in EffectDAO is currently a bit involved as it requires 4 actions: a new cycle must be created, the recycle strategy must be executed, the proposals have to be processed, and the active cycle must be updated.
This process can be done in 1 action handled mostly by the smart contract. This will reduce potential mistakes and cycle delays, while sacrificing a bit of flexibility. After 11 cycles the flexibility of executing the steps by hand is no longer needed.
daoproposals
contractprocesscycle
A percentage of the task rewards on the platform should be collected as a network fee.
Effect Network will implement a network fee that is collected by the DAO to sustain the development of the network.
With the mainnet release all the smart contract technology is in place to implement this in a decentralized way. The goal is to have the fees be collected completely autonomous (so it happens automatically, no manual actions) and as real-time as possible.
The fee parameter will be an extremely important parameter for the network - as both workers and requesters will be impacted by the value.
feepool.efx
must have a vaccount to collect funds.payout
action, split the payout between the worker and the network feeSo, I've created a campaign with a batch of 4 tasks.
r = campaign.create_batch(
e,
0, # campaign id = 0
[
{ 'image': 'https://ipfs.effect.ai/ipfs/QmVuSBpoSEUdHmB2owcbAQnModzfcbEme6w6nCkJDDJcy4'},
{ 'image': 'https://upload.wikimedia.org/wikipedia/commons/thumb/8/89/Attentive_%2815531899006%29.jpg/1920px-Attentive_%2815531899006%29.jpg' },
{ 'image': 'https://upload.wikimedia.org/wikipedia/commons/thumb/4/40/Comparison_carbon_dioxide_water_phase_diagrams.svg/1024px-Comparison_carbon_dioxide_water_phase_diagrams.svg.png' },
{ 'image': 'https://upload.wikimedia.org/wikipedia/commons/5/54/Borphase.jpg' }
],
'300.0904 EFX', # reward, thus => tasks * reps * 24.4242 EFX = reward
2, # reps
)
But as I go through it, at the end, I still get a reservation with a task_idx === 4
{
"id": 4,
"task_idx": 4,
"account_id": 3,
"batch_id": 0,
"reserved_on": "2023-10-11T12:37:05",
"campaign_id": 0
}
So, I think it gets incremented by 1 too many at the end.
Embeds don't look nice, would be nice to have opengraph metadata available on all the dashboard pages and proposal pages so things look nice when posting a link in social media.
If you click on 'Edit this page in GitHub' link at the bottom of this page: (and a few others) https://docs.effect.network/Effect-Network/about.html , it gives you this 404 error: The 'effectai/effect-network' repository doesn't contain the 'docs/Effect-Network/dapp-ecosystem.md' path in 'master'.
Effect Force Smart Contract Action payout action.
In the effect force payout action, currently it payouts for one payment at a time, is it better to calculate the amount and send it in one vtransfer.
void force::payout(uint32_t account_id,
std::optional<eosio::signature> sig) {
payment_table payment_tbl(_self, _self.value);
payout_params params = {13, account_id};
require_vaccount(account_id, pack(params), sig);
auto payment_idx = payment_tbl.get_index<"acc"_n>();
auto itr_start = payment_idx.lower_bound(account_id);
auto itr_end = payment_idx.upper_bound(account_id);
uint64_t amount = 0;
static bool got_sym;
eosio::extended_symbol sym;
for (; itr_start != itr_end;) {
auto& payment = *itr_start;
bool time_is_after_period = compare_time(payment.last_submission_time.sec_since_epoch(), date_in_sec);
if(!got_sym) {
got_sym = true;
eosio::check(payment.pending.get_extended_symbol().get_symbol().is_valid(), "symbol is not valid.");
sym = payment.pending.get_extended_symbol();
}
if (time_is_after_period == true) {
amount += payment.pending.quantity.amount;
itr_start = payment_idx.erase(itr_start);
}
}
eosio::check(amount != 0, "amount is zero.");
eosio::extended_asset payment_asset = eosio::extended_asset(
amount,
sym
);
eosio::check(payment_asset.get_extended_symbol().get_symbol().is_valid(), "symbol is not valid.");
action(
permission_level{_self, "active"_n},
_config.get().vaccount_contract,
"vtransfer"_n,
std::make_tuple((uint64_t)_config.get().force_vaccount_id, (uint64_t)account_id, payment_asset, std::string(""), NULL, NULL))
.send();
}
We're currently compiling with cdt 1.5
Probably there'll be quite some changes: https://github.com/EOSIO/eosio.cdt/releases/tag/v1.6.0
Once a cycle is processed the votes are aggregated in the cycle table and can be removed from RAM.
The frontend (Dashboard) currently assumes this data to be available so had to be adjusted. This info can either be removed from the interface or be served by a backend
The token contract and symbol are now passed as an argument to issue
during swap.
This is not save. For a more general purpose contract the symbol and token contract should be linked to the asset id of the transaction. We have to be careful with validating the symbol precision if we allow for dynamic tokens.
A more straightforward solution for now is to hardcode the EFX token for the current swap
It should be possible to change to owner of a campaign
This action should only be callable by the current campaign owner.
A use case is to delegate your campaign to the task proxy temporarily. This is an important feature for allowing anyone to post batches.
setowner
action (or add this as a parameter to update
)The data
field of the submission
struct in force.hpp
should be optional. At the moment there is no way to make a distinction between a reserved task and an empty submission.
Given a batchid
the corresponding batch needs to be deleted.
What should the limitations be?
Only the owner of the batch should be able to delete the batch.
What should happen with the rest of the efx stored in the batch?
This also raises the question about what to do with the funds in the batch.
What if there are users who have completed tasks in the batch, but have not yet claimed their task reward.
Where will the funds be stored until the user has claimed the task reward?
Or maybe the requester can only pause the batch, until all users have claimed their rewards.
The implementation should be relatively easy, there should be a couple of other examples where this is already implemented. Look at this one as an example:
effect-network/contracts/force/force.cpp
Line 52 in 8f9f51d
After an unstake action, the contract can send a deferred refund transaction after the unstaking time. Then users don't have to manually trigger a refund. A manual refund will still be possible in case the deferred transaction gets dropped.
A DAO proposal should be able to execute a user defined EOS transaction.
If a proposal passes it should be possible to execute an eosio.msig
transaction owned by the DAO. This transaction will bear the [email protected]
permission, which will allow the DAO to make restricted transaction like updating code or modifying network parameters.
[To be refined]
This is the implementation of Proposal-22: https://dashboard.effect.ai/proposals/22
The goal is to create a dynamic vote weight system where your vote weight is determined by EFX Power and staked NFX. Ranks will be removed from EffectDAO and the minimum entry for voting will be lower.
The vote weight formula will become:
vote_weight = min(staked_nfx, efx_power / 20)
A quick overview of the changes that are needed:
get_vote_power
in effect-dao-shared.hpp
and remove references to ranks.effect-proposal
and effect-dao
contracts.effect-proposals::processcycle
will have to be tested and redesigned to support a large number of voters.This proposal will make a lot more DAO member eligible to vote but also makes it easier for large token holders to accumulate more vote weight. A quick analysis of the vote distribution looks healthy but we should keep paying attention to keeping the system fair. A quick reference to the current and new vote distributions:
With the new distribution there will be a lot more users in the DAO. It can also grow quicker because of the low entry barrier. The theoretical maximum number of Guardians right now is 1,000 (with a practical limit of around 400). With the new system there can be over a million Guardians.
The process cycle action has to become scalable. We can start by processing each proposal independently in an action, which will make process cycle trivial. Secondly the new process proposal action should be able to work in batches so it can run over several actions.
The most important component to test is the correctness of fee distribution. This update should be accompanied by extensive e2e tests for a range of scenarios.
There should be a time limit on posting swap transactions so that used RAM can be freed at some point in time.
A recent proposal was accepted to burn a part of the feepool before reward distribution:
https://dashboard.effect.ai/proposals/17
This feature needs to be researched and implemented in the feepool smart contract.
By voting yes on this proposal, you endorse the team establishing a toggleable mechanism in the smart contract that can burn 50% of network fees prior to distribution when enabled (or publishing a proposal on such a thing if this proposal is insufficiently technical). Initially, it will be disabled and another proposal will be required to enable network fee burning.
the current implementation of releasetask makes use of a for loop to get the vaccount id of the campaign owner. This for loop is too excessive logic wise, it should be possible to get the same result with the find method of the multi_index with the second index ("token" on vaccount).
Users should be able to select multiple tokens as payment for their proposal, like NFX or EOS, instead of just EFX.
Effect DAO currently supports 1 currency as payment for a proposal. The smart contract design already supports multiple tokens but for simplicity this has been disabled. In recent DAO calls we discussed the need to allow NFX and EOS to be paid as rewards.
This proposals smart contract will need a small update to enable support for multiple tokens.
A side note on security: it should not cause much problems to allow arbitrary currencies. If someone adds currencies the DAO does not own this should be detected by the UI so people won't vote on it, and the proposal will not be able to execute anyways. There is a small risk of the spent
map of the cycle to consume a lot of RAM, but this only gets populated for approved proposals anyways.
Uncomment, finish, and thoroughly test multi-currency support in processcycle
:
https://github.com/effectai/effect-network/blob/master/contracts/proposals/proposals.cpp#L176
Add e2e tests with multiple pays
Implement frontend feature in effect-dao repo
Currently, to post NEO transactions in posttx
, the active permission of the swap account is required.
It's probably more convenient if we allow different, assigned, accounts to use posttx
As a user I want to get back the RAM for old submissions
Submissions for batches that are no longer active should be removed the the EOS table to clear RAM
Figure out how to add a method to the sdk that will let users easily add their campaign to efxtaskproxy.
Either it is a checkbox in the campaign creation form, or programmatically in the sdk.
Probably an action needs to be created to adjust the permissions on eosio.
An alternative is to let the owner of the campaign transfer their ownership of the campaign to Effect Network's efxtaskproxy.
The problem here is that they will not be able to edit their campaigns anymore.
This feature needs to be thought out further to make sure that it is a solid process that users and devs can rely on.
Refund deposited EFX when deleting a bach
When removing a batch the EFX currently gets stuck in the force account. It should be possible to get these funds back when removing a batch.
TBD
Currently the stake contract pays all RAM for stakes. By having users open a 0 balance entry before they can stake they can pay the RAM for their own stakes
This relayer will be an HTTP service that is responsible for several features that require some centralized coordination in the network:
Urgently:
In the future:
I think it makes most sense to perform this conversion inside the smart contract. Currently the posttx
step is assumed to receive a 1e4 int formatted amount. When it receives a raw NEO amount (1e8) it will have to round it to lower precision.
The unstake_delay in the staking contract should be adjustable
With this action the DAO could adjust the unstake time of EFX and NFX through an ATP.
update
action but to update the stats
table of a tokenBSC users should pay an extra fee when receiving a payout for their work.
This fee is to cover the use of the relayer.
This covers the following DAO proposal: https://dao.effect.network/proposals/141
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.