We have friends and colleagues that we only meet online and we run businesses across the globe without leaving our houses.

Social media platforms such as Google or Instagram (among others like eCommerce, Home banking, etc) have become an indispensable part of our lives. Can you just think of a life without access to Google or Instagram? Losing access to our digital life could be devastating to us.

With that strong and important statement, some interesting questions arise: Are our digital life really ours? Do we really own our Google or Instagram (or any other) account? Is our digital identities under our control?

TL;DR;
No, but there is hope.

Before we can dive into the weeds to answer those questions, we need to understand what digital identities are. Let’s get into it…

Identity

We could define an identity as a set of attributes that describe a person or an organization, such as First Name and Last Name. Every human being, as well as all organizations of any kind, has an identity. That identity allows us to identify that person or organization uniquely so that we can have trusted interactions.

The concept of identity is so native and intrinsic to us that we don’t even realize it, but whenever we interact with someone (either a person or organization) we identify that person (or organization) by inspecting her/his/its identity. For example, I know I am talking with a friend of mine (and not with someone else) cause I can recognize his voice on the other end of the phone. In the same way, a policeman knows I am authorized to drive by inspecting my driver’s license.

What is not obvious to us is that we don’t have just one identity, but many. Depending on the context, we use one identity or the other. What’s interesting about this multiple identity fact is that is not us the ones who decide which identity is valid, but rather the one that needs to identify us, the verifier.

For example, in a phone call with my friend, it is my friend the one who only requires my voice to identify me (which is unique) and vice versa. However, in the policeman example, they need something stronger, they need an identity that the Government issued (which has a number as the unique factor, plus certain proofs).

Digital Identities

A digital identity has the same principles described above but applied to our digital life. Every social media platform, home banking account, eCommerce and so on we use, represents one of our many identities. For example, if we have a GitHub account then that’s one identity of us, same for Google or our Home banking account.

In many cases, we want to use the same identity on other platforms, such as when we sign in with Google to the News website. In many other cases, we don’t want to “reuse” our identity and create a new one. Some platforms just force us to create a new specific one (like Instagram).

Commonalities

As we have seen, all identities (both physical and digital ones) have certain aspects in common.

They have some sort of unique factor. It can be a unique number (such as our Driver’s license), an email (in the case of Google), a handle (for X), or our voice tone. In some cases, this unique factor is a combination of some ID plus some context. For example, my Student ID is just a number. It only makes sense if I state the University I am a student of. In other words, some identities have a unique identifier strong enough that don’t need anything else (such as Google emails), while some others require the unique identifier plus the issuer (such as a Student ID).

They all have an issuer. The government in the case of a Driver’s License, Google in the case of my email account, or the University in the case of a Student ID. We also self-issue identities, for example, I can identify myself as a fan of a certain Football team. But in all cases an Identity without an issuer becomes useless.

They all describe certain attributes of the subject. For example, my driver’s license contains an expiration date and list of vehicle categories I am allowed to drive, my Google account includes a nickname and my Student ID indicates an enrollment day.

Some attributes are scoped to the context of the Identity they represent, for example, the expiration date of the Driver’s License only makes sense when I need to prove I am authorized to drive. However, some other attributes have a broader scope, such as my Driver’s License, which also has my first and last name along with my ID number.

Physical identity ownership

Before discussing where the fallacy comes from, we must first state the main attribute non-digital identities have: we own them.

When physical identities are issued, they are printed in a sort of plastic credential that we hold. Once the Government issues a driver’s license to me, that driver’s license stays with me and cannot be taken away from me. The issuer of that identity cannot deny having issued it.

Yes, a driver’s license has an expiry, but it is mine and still authentic. In other words, even though I might not be able to drive anymore due to my driver’s license expired, that identity is still mine. I can prove that sometime in the past I was authorized to drive just by holding the driver’s license, as an individual I don’t depend on anyone else.

The fallacy of ownership with digital identities

With digital identities, however, that statement is not true.

They are not ours by any means. We might never have thought about this, we don’t own our social media platforms such as Google or Instagram, at least not in the way we think. We are the only ones (hopefully) to have access to the account as we are the only ones in control of the password, but this is not sufficient to put us under control of it.

X or Instagram, for example, could decide to ban us or block us from their platforms for arbitrary reasons. Meta might go bankrupt and simply disappear (I know this sounds like an impossible fact, but who would have imagined Blockbuster would disappear 20 years ago).

This is because our digital identities (all of them) depend on centralized organizations that control how, who, and when our identities are accessed. They own the services and infrastructure components needed for authentication. If those services go offline we are unable to access our accounts.

There is hope

With the emergence of decentralized technologies, now it is possible to put digital identities under user control again. Distributed ledgers and blockchains play a fundamental role in this journey.

Decentralized technologies allowed us to create open and public decentralized infrastructure components that don’t depend on a single individual or organization, but rather on the whole community. This new decentralized infrastructure opened a new world of possibilities.

Decentralization. This is probably the most prominent aspect. Blockchains, for example, do not depend on a single organization not individual, but rather on multiple actors that collaborate to support the network. This means that even if a significant participant goes offline, there will still be other participants available.

Transparency. The Open & Public nature of decentralized technologies, especially distributed ledgers, ensures that rules are clear to everyone. No actor can apply arbitrary behavior unexpectedly, such as banning a user due to some content that broke some rules that only the actor was aware of.

Cryptographically secured. Through cryptography, we can have trust-less interactions that anyone can verify without depending on centralized authorities. This also serves as a non-repudiation mechanism, since issuers cannot refuse having signed a piece of data or operation.

What’s in the future

Blockchains or decentralized ledgers by themselves are not enough to put digital identities back under users’ control, but they set up the foundations, the stepping stone to build the mechanisms needed.

In this direction, two significant and very promising solutions are growing fast: Decentralized Identifiers (aka DIDs) and Verifiable Credentials (aka VCs).

Decentralized Identifiers

Also known as DIDs, They enable us to uniquely identify entities (such as individuals, organizations, and systems) in a decentralized manner. We don’t need any central authority to issue them nor any centralized infrastructure to resolve them., anyone can create and publish their own DID.

There are many different methods for creating DIDs. We can use well-known blockchains such as Bitcoin or Ethereum. There are also other distributed technologies such as IPFS or Distributed Hash Tables (aka DHT, which is the underlying implementation of BitTorrent). Additionally, they are cryptographically secured by using a Public-Private Key schema. The owner of the private key controls the DID, effectively giving control back to the user.

See this excellent blog by Nicolas Antinori if you want to understand the differences between public keys, private keys, and seed phrases.

Verifiable Credentials

Or just VCs, enable Entities (users, organizations, and systems) to issue Credentials that are cryptographically secured and fully decentralized. VCs are tamper-resistant as they contain digital signatures created by the issuer. Verifiers can prove that claims included in a VC are valid and authentic by inspecting and validating its digital signature.

All VCs have a subject (that represents the holder of the credential) and an issuer (that represents the entity that emitted it), both identified by DIDs. Anyone can verify who the credential belongs to and who issued it. Due to the decentralized nature of DIDs, there is no need for central authorities.

Both together are establishing the foundations for the next generation of identity models, whereas we as users can truly control our digital identities: Self-Sovereign Identity.

Conclusion

While in the current state of the art, our digital identities are outside of our control, we are moving towards a more decentralized model. We are building, step by step, the tools and mechanisms that will allow us to be more independent.

Thanks to Decentralized identifiers and Verifiable credentials, we will no longer depend on big corporations to identify ourselves or to identify others. We will see a lot of innovation and improvement in the digital identity space in the upcoming years towards Self-Sovereign Identity.

If you’d like to learn more about SSI, DIDs and, VCs, stay tuned!

The post Digital identities: The fallacy of ownership appeared first on Mighty Block |.

In this article we will try to discover the caveats that must be taken into account when dealing with mappings, particularly from our DApp perspective.

A brief introduction

Mapping is a type that allows the storing of key-value pairs, something that developers coming from C#, JavaScript or Java know as Dictionaries, Hash Maps or Hash Tables.

Keys must be unique and used to access the value. Below is a mapping example:

contract Mappings {
    // Mapping declaration
    mapping (address => uint256) public balances;

    constructor Mappings() {
        // Assignment
        balances[0xFEC72b6c4ec23F7E9FbEd61E3FE0A8198e7BA81B] = 50;

        // Retrieval
        uint256 balance = balances[0xFEC72b6c4ec23F7E9FbEd61E3FE0A8198e7BA81B];
    }
}

Some peculiarities

Without entering into the low level characteristics too much and keeping the focus, below are two of the most important aspects of mapping which must be carefully taken into account when designing DApps.

For a deep dive into solidity maps, check out this article.

Cannot be iterated

Mapping function in solidity, by design, cannot be iterated or enumerated as in other languages. This is because they do not keep track of the elements so there is no length or count property. Most importantly, its elements store in a storage position based on the hash of the key.

No null value

Solidity does not support the concept of null or nil so if we try to access a key that does not contain a value we will get the default value, as opposed as other languages where we would get a null value.

This means that we will always get a value, the default value, even if the key does not exist. Following the balances example, we will get this:

const address ACCOUNT_WITH_BALANCE = 0xFEC72b6c4ec23F7E9FbEd61E3FE0A8198e7BA81B;
const address ACCOUNT_WITH_NO_BALANCE = 0x000000004ec23F7E9FbEd61E3FE0A81900000000;

// Balance will be 50
uint256 balance = balances[ACCOUNT_WITH_BALANCE];

// Balance will be 0, the uint256 default value
uint256 balance = balances[ACCOUNT_WITH_NO_BALANCE ];

What does all that mean?

It means that once you create a map and deploy it there is no way for us, as DApps developers, to know what the contents of the mapping are.

Following the balances example, where an account can have zero balance, we will always get a value for every single address we try.

For those cases where we get something different than zero, we can assume then that account is part of the mapping (or a user of our DApp), but what if we get a zero? Could we know if this is an account that has never operated the contract? or one that has been operating the contract but has zero balance?

No… we could not.

Why is that important at all?

The simplest use case is a user reporting a bug where some balance suddenly went to zero. Probably the very first step in the analysis would be to discover whether the user has ever operated at all.

In more advanced situations, we might need to migrate all the balances to another gas optimized version of the smart contract. Or we might just want to get some statistics, who knows…

The example is extremely over simplified and there are many strategies to mitigate that situation, but bear with me as we want to keep the example focused and simple.

One of the most common situations is dealing with these requirements once our DApp is in production. At that point, it is usually too late and the solutions typically imply extreme creativity and expertise.

That is why it is so important to consider alternatives even before designing our smart contracts. Let us see what some of those alternatives might be: To track or Not to track… that is the question.

To track

One of the options implies adding some centralization to our DApp. We can do that tracking via a backend service the activity that is taking place in the mapping.

In simple words and continuing with the balances example, store a copy of the balances in a separate store, like a table in a database.

We could have a table in a PostgreSQL database that could look like this:

This approach is very simple to understand and enables us to retrieve information without having to query the blockchain. Even though querying the blockchain does not cost any gas, during peaks, it can become slow so creating a poor user experience.

However, this not only implies introducing a backend piece (in case it was not part of the DApp already) but also keeping the smart contract in sync with our database.

In the case that the smart contract is being accessed both from the Back End and directly from the blockchain, we will have to thoughtfully design and emit events so that our Back End component can both listen to them and update the database.

Not to track

Alternatively to the centralized approach, we can introduce a fully blockchain-oriented solution: Enumerable Mappings.

This approach consists of keeping track of the mapping keys in a separate array so that we can iterate over the array and use those indexes to access the mapping. A very simple implementation would look like this:

contract BalancesMap {
    mapping(address => uint256) public balances;
    address[] internal accounts;

    function add(address account, uint256 balance) public {
        balances[account] = balance;
        accounts.push(account);
    }

    function count() public view returns (uint) {
        return uint(accounts.length);
    }
    
    function getAccounts() public view returns (address[] memory) {
        return accounts;
    }
}

With this solution we can solve the previously stated problem where we did not know which keys were in use, as now we not only keep track of the keys for iterating later, but also we can get the list of keys straight away.

Conversely, we are introducing more complexity and in cases where we just need one account, we still have to iterate over the whole list. It also implies more storage usage, and consequently more gas.

I strongly suggest not implementing your own solution and rely on OpenZeppelin EnumerableMap instead.

The equilibrium

Both approaches, as we have seen, have pros and cons. But how can we decide which one is better?

In most cases, combining both is probably the answer. But that is not always possible. I usually follow the guidelines below when making a decision:

• If our use-case is gas sensitive or we have some restrictions in terms of gas, then using tables is a better choice.
• If your DApp requires some analytics or background processing, then using tables can be a requirement.
• If our DApp is fully decentralized, use Enumerable Maps.
• If we don’t have a Back End component or balances change too often (which makes syncing extremely complicated), using Enumerable Maps can be beneficial.

This guideline is far from being perfect and is intended to serve as a trigger for discussion. Each use case is unique and deserves careful consideration.

Conclusion

Mappings are extremely powerful and flexible, but present challenges that, if not considered from the start, can lead to extremely difficult situations to overcome. The strategy we choose depends largely on the use case we are trying to solve, nonetheless, doing a proper analysis in earlier stages can make our life much easier.

We are always looking for Web3 talent !

Mighty Block is one of the partners of Forte, a platform to enable game publishers to easily integrate blockchain technologies into their games. We believe blockchain will enable new economic and creative opportunities for gamers around the world and have assembled a team of proven veterans from across the industry (Kabam, Unity, GarageGames, ngmoco, Twitch, Disney), as well as a $100M developer fund & $725M funding, to help make it happen. That’s where you come into play.

Feel free to browse all our current open job opportunities in the following link

The post Mappings in Solidity: To track or not to track appeared first on Mighty Block |.