Forum for discussion of mid, final term and final project

Clarifying remarks about the final term (and project)

Clarifying remarks about the final term (and project)

di DAMIANO DI FRANCESCO MAESA -
Numero di risposte: 8

A few remarks risen from your questions during question time. Anyway, when in doubt, remember to always justify your design/impelemntation choices in your submission.

1. Content identifiers: you can use as content identifier any piece of information that seams meaningful for customers to identify the content. The simple solution of using a short string is all right for the assignment, assuming that in reality those strings allow customers to uniquely identify the content. For example they could represent the title of a song for music content. YOU CAN ASSUME SUCH IDENTIFIERS TO BE UNIQUE. Some of you are using content manager addresses instead of titles/strings. This solution needs to be justified in your submission as an address is not an immediate way to identify a content by an human customer, without further passages (i.e. querying the corresponding contract for further information).

2. GetNewContentsList(x), GetLatestByGenre(x), etc. methods: for all those kinds of methods there are two opposite simple implementation approaches. The first one is to store additional information on the catalog smart contract to allow it to keep the relevant lists updated. This incurs in an increase of gas expenses for such contract and most content addition or consume operations. The second solution is to leave all the burden to build the lists at request time to the consumer calling the methods. The two solution are a tradeoff between gas consumption and execution complexity/time. In designing your solution and potentially choose between one of the two approaches do keep in mind the following points:

- constant functions do not consume gas but are a burden for the client executing them.

- the gas paid for a transaction is a cost for the transaction creator. Always keep in mind if the gas payer really is the one that will benefit from the gas spent. E.g. is it correct in your scenario that a content creator will have to pay more gas to ease a functionality used by customers? If not trivial, always justify your choices.

3. Time measurment: in a blockchain scenario there is no concept of global clock or exact time, but yet smart contracts need to be globally deterministic. This is why we advise to use block height as time measurement.


In riposta a DAMIANO DI FRANCESCO MAESA

Re: Clarifying remarks about the final term (and project)

di ANDREA LISI -

A question about 1. , i.e. content identifiers.
Using string as content identifier makes everything more human readable and easier for us to debug.

It seems to me intuitive for getContentList() to return an array of string. Unfortunately, it is not possible to return a string[] in solidity unless we provide pragma experimental ABIEncoderV2 which enables experimental features. But Remix itself warns "Do not turn on experimental features on live deployments".

So, for sake of the final term, is it ok to use those functionalities? Or we would have problems later while developing the DApp?

Otherwise, we would need to return an array of fixed-size type (such as bytes32, address etc) and doing so we force the user to perform a second step to transform every element to string one by one (for example by using a pure function bytes32ToString(bytes32 _s) pure returns(string) or getTitle(address _a) returns(string) ). This is possible if we assume that a content identifier has a maximum length: https://stackoverflow.com/questions/42716858/string-array-in-solidity.

In riposta a ANDREA LISI

Re: Clarifying remarks about the final term (and project)

di DAMIANO DI FRANCESCO MAESA -

Even if it may seem weird form a traditional programming language point of view, strings are seldom used in Solidity. If you inspect the real smart contracts on the Ethereum blockchain as well as the template ones, most of them use byte arrays (usually bytes32[]).

This is the solution we recommend as well, use the maximum length assumption.

As hinted in the question this is not really a problem at this stage (you just pass/read a different parameter in remix), while it would need more management while writing the final project.


In riposta a DAMIANO DI FRANCESCO MAESA

Re: Clarifying remarks about the final term (and project)

di ANDREA LISI -

As far as I understad we could store our information as bytes32[] (I guess they are less gas costly than string[]).
For this reason we assume a MAX-LENGTH.
But we would like for the user to access to the contents by string, because it is more user friendly than writing bytes.
This would imply an on-the-fly conversion (string => bytes32) before storing the input (this will consume user's gas).

But as soon an user would like to see the list of the contents (by calling getContentList()) we have two possibilities:

1) return the bytes32[];
2) return a string[].

For the (bytes32 => string) conversion I have found this function.
In case 1) the user should call by himself the function to decode every bytes32 received;
In case 2) the getContentList() will convert every element of its state before returing the result.

In both cases the user won't pay in gas, but in 1) the user should perform conversions manually (one content at a time).
Solution in 2) is "coherent" with the choice to ask for a content providing a string, but isn't possible to implement in solidity unless we use the experimental features.

Thanks in advance

In riposta a DAMIANO DI FRANCESCO MAESA

Re: Clarifying remarks about the final term (and project)

di MARCO DEGL' INNOCENTI DETTO LUCCHESI -
For time measurment using block height we have to use something like this? 

current_block_number + ((future_time - time_now) / average_time_to_mine_a_block) where

average_time_to_mine_a_block is 14 seconds about? Thanks


In riposta a MARCO DEGL' INNOCENTI DETTO LUCCHESI

Re: Clarifying remarks about the final term (and project)

di DAMIANO DI FRANCESCO MAESA -

I would rather use smething simple: measure all time in block height difference instead of seconds, and simply consider the current block height as current time.

In riposta a DAMIANO DI FRANCESCO MAESA

Re: Clarifying remarks about the final term (and project)

di DAMIANO DI FRANCESCO MAESA -

In the assignment text, substitute the paragraph:


The Catalog contract collects all the payments from the users and redistribute payouts among authors, granting a fixed payout for every content access. The Content Management Contract must be written to prevent views tampering. For the sake of simplicity, we do not consider Premium Account content fruitions in the view count.


With:


The Catalog contract collects all the payments from the users and redistribute payouts among authors, granting a fixed payout for every v content views (the payout is triggered each time v new views are reached). The Content Management Contract must be written to prevent views tampering. For the sake of simplicity, we do not consider Premium Account content fruitions in the view count.




In riposta a DAMIANO DI FRANCESCO MAESA

Re: Clarifying remarks about the final term (and project)

di ALDO D'AQUINO -
According to the assignment the subscription time is measured in hour:

"enabling an unrestricted access to any content for x hours".

Considering that 1h = 3600s and actually the average block-time is 14.9 (https://etherscan.io/chart/blocktime) there are 240 blocks in an hour.

So, the subscription ends after x * 240 blocks, is that right?

In riposta a ALDO D'AQUINO

Re: Clarifying remarks about the final term (and project)

di DAMIANO DI FRANCESCO MAESA -

The assignemnt text has been refiend accordingly:

Premium accounts require the payment of a fixed sum coverig a period of time, so enabling an unrestricted access to any content for x time (expressed either in hours or in block height difference), starting from the subscription time.

In general since you are requested to choose x, there should be no need for hour/block height conversion. Just choose one of the two to measure time and stick with it (e.g. if you choose block height, then subscriptions last for x blocks).