Sviuppi Qubic: aggiornamento 3 settembre 2018

in iota •  6 years ago  (edited)


Sviluppi Qubic: Eccoci al 3 settembre 2018. La IOTA Foundation ha pubblicato un articolo per aggiornarci sugli sviluppi. A sorpresa troviamo degli esempi di codice ABRA!

Agosto è stato interamente dedicato alla pulizia dei dettagli del linguaggio di programmazione per Qubic: Abra. Sono stati finalizzati molti dettagli associati alla sintassi della lingua ed hanno iniziato a comprendere gli aspetti di implementazione dell'esperienza utente del progetto. I risultati sono promettenti ed hanno consolidato la convinzione che verso la fine 2018 sarà possibile mostrare un'implementazione proof-of-concept di Qubic.

È iniziata la documentazione del modello computazionale di Qubic. Il documento approfondisce il modo in cui un programma Abra viene tradotto in una rappresentazione intermedia del codice trit che si chiama Handy. Il documento specificherà inoltre in che modo il codice interagirà con il Qubic Dispatcher, che è l'attività qubic ed il dispatcher di eventi su nodi abilitati Qubic.

Handy codifica il programma Abra in una rappresentazione trinaria compatta in modo che possa essere facilmente impacchettato in una transazione Qubic e pubblicato sul Tangle. Handy avrà eseguito la verifica della sintassi e la segnalazione di eventuali errori nel programma Abra prima che avvenga la pacchettizzazione, il che significa che qualsiasi strumento di post-elaborazione, come il Qubic Dispatcher, non dovrà più farlo.

Qubic Dispatcher gira su un nodo abilitato Qubic e tradurrà il codice-trit qubic nella sua architettura di destinazione. Il dispatcher ascolterà anche gli eventi che possono attivare i qubics e passarli a quei qubics per ulteriori elaborazioni. L'elaborazione del codice qubic è strettamente intrecciata con il dispatcher come chiarirà la documentazione.

Il documento del modello di calcolo di Qubic è il prossimo ad essere messo in cantiere. Le sue due parti principali riguarderanno la sintassi di Abra e l'interazione con il dispatcher.

L'altro documento che dovrebbe essere pronto all'incirca nello stesso periodo è il documento sulla matematica alla base di Qubic. Il layout iniziale è completo ed in questo momento stanno completando le informazioni sostanziali delle varie sezioni.

Nel frattempo, il lavoro sul compilatore Abra sta procedendo bene. Al momento si stanno includendo le ultime versioni della lingua e si sta finalizzando la generazione del codice LLVM. Questo dovrebbe consentire di eseguire e testare il codice Abra in maniera semplice e diretta. Successivamente verrà creato il dispatcher e l'intera interazione tra il codice e il dispatcher dovrebbe consentire la creazione ed il test di programmi molto più complessi.

L'implementazione FPGA è stata studiata in parallelo in modo che il processo di progettazione la tenga sempre presente. Ricordiamo che l'obiettivo principale è il calcolo distribuito a risparmio energetico per l'Internet of Things.

A causa di questo obiettivo, è stato deciso di posticipare ulteriori lavori sul concetto di gateway (per movimentare i fondi con Qubic) fino a quando non sarà stato raggiunto il punto in cui si possa effettivamente eseguire qubics nella loro interezza. Tali gateway necessiteranno innanzitutto di un sistema completo, per essere implementati e testati.

Hanno anche iniziato a cercare nuovi membri per il team Qubic perché si pensa che il design generale sia ora abbastanza stabile. Hanno identificato le parti dove le persone possono lavorare contemporaneamente.

Tutto sommato è stato un mese emozionante con molte intuizioni e l'entusiasmo per il progetto Qubic è cresciuto.

Bonus: alcuni esempi di Abra


// sample Abra type definitions
// define some standard trit lengths we will use in our examples
// note that you can define the optimal size for any type's range
// to reduce energy requirements accordingly
Trit [1]; // -1 to +1
Tryte [3]; // -13 to +13
Short [9]; // -9,841 to +9,841
Int [27]; // -3,812,798,742,493 to +3,812,798,742,493
Long [81]; // -2.217...e+38 to +2.217...e+38
Hash [243];
State [729];
// convenience type to make code more clear
// supposed to always contain a binary boolean value 0 (false) or 1 (true)
// should never be null or have the value - (convention not enforced by Abra)
Bool [Trit];
// here's how to define a named structured trit vector
// it consists of the concatenation of all sub-vectors
// its size is the sum of all sub-vector sizes
// IOTA transaction layout
Transaction {
signature [27 * Hash]
, extradatadigest [Hash]
, address [Hash]
, value [Long]
, issuancetimestamp [Int]
, timelocklowerbound [Int]
, timelockupperbound [Int]
, bundle [Long]
, trunk [Hash]
, branch [Hash]
, tag [Long]
, attachmenttimestamp [Int]
, attachmenttimestamplowerbound [Int]
, attachmenttimestampupperbound [Int]
, nonce [Long]
};
// sample Abra look-up tables
// these are a look-up tables, or LUTs
// a LUT describes for each combination of input trits what the resulting output trits will be
// any missing explicitly defined combinations will cause the resulting output to be null
// if any input to a LUT is null, the result will be null as well,
// so we only need to specify combinations of non-null input values
// ************* BINARY OPERATORS *************
// LUT logic: binary NOT
// return !trit1;
not [
0 = 1;
1 = 0;
];
// LUT logic: binary AND
// return (trit1 & trit2);
and [
0,0 = 0;
0,1 = 0;
1,0 = 0;
1,1 = 1;
];
// LUT logic: binary OR
// return (trit1 | trit2);
or [
0,0 = 0;
0,1 = 1;
1,0 = 1;
1,1 = 1;
];
// LUT logic: binary XOR
// return (trit1 ^ trit2);
xor [
0,0 = 0;
0,1 = 1;
1,0 = 1;
1,1 = 0;
];
// LUT logic: binary NAND
// return !(trit1 & trit2);
nand [
0,0 = 1;
0,1 = 1;
1,0 = 1;
1,1 = 0;
];
// LUT logic: binary NOR
// return !(trit1 | trit2);
nor [
0,0 = 1;
0,1 = 0;
1,0 = 0;
1,1 = 0;
];
// LUT logic: binary XNOR
// return !(trit1 ^ trit2);
xnor [
0,0 = 1;
0,1 = 0;
1,0 = 0;
1,1 = 1;
];
// ************* TERNARY OPERATORS *************
// LUT logic: return the negative value of the input trit
// return -trit1;
/ note that making an entire trit-vector value negative
// can be done by simply negating every trit in the vector
neg [
  • = 1;
    0 = 0;
    1 = -;
    ];
    // LUT logic: return a boolean indicating whether the two input trits are equal
    // return (trit1 == trit2);
    equal [
    -,- = 1;
    -,0 = 0;
    -,1 = 0;
    0,- = 0;
    0,0 = 1;
    0,1 = 0;
    1,- = 0;
    1,0 = 0;
    1,1 = 1;
    ];
    // LUT logic: return a boolean indicating whether the two input trits are unequal
    // return (trit1 != trit2);
    unequal [
    -,- = 0;
    -,0 = 1;
    -,1 = 1;
    0,- = 1;
    0,0 = 0;
    0,1 = 1;
    1,- = 1;
    1,0 = 1;
    1,1 = 0;
    ];
    // LUT logic: when (boolean) trit1 equals 1 return trit2 else return trit3
    // return trit1 ? trit2 : trit3;
    unequal [
    0,-,- = -;
    0,-,0 = 0;
    0,-,1 = 1;
    0,0,- = -;
    0,0,0 = 0;
    0,0,1 = 1;
    0,1,- = -;
    0,1,0 = 0;
    0,1,1 = 1;
    1,-,- = -;
    1,-,0 = -;
    1,-,1 = -;
    1,0,- = 0;
    1,0,0 = 0;
    1,0,1 = 0;
    1,1,- = 1;
    1,1,0 = 1;
    1,1,1 = 1;
    ];
    // LUT logic: return the 2rd input trit only when 1st input trit equals 1 (true)
    // return (trit1 == 1) ? trit1 : null;
    nullOrTrit [
    1,0 = 0;
    1,1 = 1;
    1,- = -;
    ];
    // sample Abra functions
    // this is a function that takes a trit vector of State [729],
    // but we don't need to constantly repeat that size since we
    // already established the size at the top of the file
    digest(state [State]) =
    // a function returns the value of its last statement,
    // which in this case is a concatenation (comma operator)
    // of the input state and the result of the transform() function
    state, transform(state, 81);
    // note that this function does not need curly braces around its single statement
    // curly braces are only necessary when grouping multiple statements
    // construct functions for all predefined types that perform
    // a similar task to the nullOrTrit LUT for those larger types
    // note that we have defined each successive type a factor 3 times bigger
    // which means we can easily define each successive type in terms of the previous one
    // every nullOrXxx function returns < val > when < t > equals 1 (true), and null otherwise
    // note that it may seem wasteful to define it this way, but when mapped to FPGA
    // these can be translated into parallel circuitry that executes them simultaneously.
    // for other architectures, Abra will allow the Abra functions to be replaced with
    // a dll function that uses optimal architecture-specific instructions.
    // we expect a library of common functions to be developed over time
    nullOrTryte(t [Bool], val [Tryte]) = {
    // concatenate the 3 separate trits via the LUT
    nullOrTrit[t, val[0]],
    nullOrTrit[t, val[1]],
    nullOrTrit[t, val[2]];
    };
    nullOrShort(t [Bool], val [Short]) = {
    // concatenate the 3 separate trytes via the previous function

// note the notation to easily specify a subrange of a trit vector
// we will start at N times the size of Tryte and have an open ended range
// which specifies to take whatever amount necessary to pass to the underlying parameter
nullOrTryte(t, val[0 * Tryte..]),
nullOrTryte(t, val[1 * Tryte..]),
nullOrTryte(t, val[2 * Tryte..]);
};
nullOrInt(t [Bool], val [Int]) = {
// concatenate the 3 separate shorts via the previous function
nullOrShort(t, val[0 * Short..]),
nullOrShort(t, val[1 * Short..]),
nullOrShort(t, val[2 * Short..]);
};
nullOrLong(t [Bool], val [Long]) = {
// concatenate the 3 separate ints via the previous function
nullOrInt(t, val[0 * Int..]),
nullOrInt(t, val[1 * Int..]),
nullOrInt(t, val[2 * Int..]);
};
nullOrHash(t [Bool], val [Hash]) = {
// concatenate the 3 separate longs via the previous function
nullOrLong(t, val[0 * Long..]),
nullOrLong(t, val[1 * Long..]),
nullOrLong(t, val[2 * Long..]);
};
nullOrState(t [Bool], val [State]) = {
// concatenate the 3 separate hashes via the previous function
nullOrHash(t, val[0 * Hash..]),
nullOrHash(t, val[1 * Hash..]),
nullOrHash(t, val[2 * Hash..]);
};
// sample old Curl implementation in Abra, just for fun
transform(state [State], round [Short]) = {
// assume subXxx() is a function that performs subtraction on trit vectors of size X
// and also returns a trit vector size X
roundMinusOne = sub9(round, 1);
// assume equalXxx() is a function that performs comparison on trit vectors of size X
// and returns a trit containing a binary boolean value of 0 (false) or 1 (true)
roundZero = equal9(roundMinusOne, 0);
// calculate the new state for this round
newState = curlRound(state);

// here comes the interesting part, we're going to use a merger operation,
// which is an operation that returns the single operand that is non-null
// note that a merger will fail when multiple operands are non-null
// this line will return newState when roundMinusOne was determined to be zero
// and null otherwise
stateOut = nullOrState(roundZero, newState);
// this line will return newState when roundMinusOne was determined to be non-zero
// and null otherwise
stateNext = nullOrState(not[roundZero], newState);
// this line will only return roundMinusone when it was non-zero and otherwise returns null
roundNext = nullOrShort(not[roundZero], roundMinusOne);
// recursively call transform to execute the next round
// note that this will only execute if either of stateNext and roundNext are non-null
// otherwise it will not execute and a null return value is assumed
// so this is essentially a conditional execution
stateFinal = transform(stateNext, roundNext);
// merge the two branches by returning the one that is non-null
// so this is kind of an implied if-then-else, because it will
// either return stateOut or stateFinal
stateOut \ stateFinal;
};
// now follows the actual implementation of a single Curl round
// LUT logic: curl the 2 input trits onto an output trit
curl [
-,- = 1;
-,0 = 0;
-,1 = -;
0,- = 1;
0,0 = -;
0,1 = 0;
1,- = -;
1,0 = 1;
1,1 = 0;
];
// a very dumb and straightforward implementation that curls all 729 state trits
curlRound(s [State]) = {
// we use the curl LUT for each of the 729 individual pairs of trits,
// and concatenate the resulting trits into a 729 trit return value
curl[s[ 0], s[364]],
curl[s[364], s[728]],
curl[s[728], s[363]],

// ... snipped 723 more lines like this ...

curl[s[366], s[ 1]],
curl[s[ 1], s[365]],
curl[s[365], s[ 0]];
};


Il testo originale in lingua inglese si trova qui: https://blog.iota.org/qubic-status-update-september-3rd-2018-f981bdfd8f26


Da oggi è possibile dare il vostro supporto su Patreon https://www.patreon.com/antonionardella

Per ulteriori informazioni in italiano o tedesco trovate i miei contatti a questa pagina.
Se avete trovato utile la mia libera traduzione, accetto volentieri delle donazioni ;)

IOTA:
QOQJDKYIZYKWASNNILZHDCTWDM9RZXZV9DUJFDRFWKRYPRMTYPEXDIVMHVRCNXRSBIJCJYMJ9EZ9USHHWKEVEOSOZB
BTC:
1BFgqtMC2nfRxPRge5Db3gkYK7kDwWRF79

Non garantisco nulla e mi libero da ogni responsabilità.


Posted from my blog with SteemPress : https://antonionardella.it/snapshot-locali-sviluppo-tangle/

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!