https://www.ledger.com/blog/ledger-live-new-earn-section-is-here-grow-your-portfolio-the-right-way

Ledger started by providing devices to support secure transactions, and has grown via its companion app Ledger Live to help provide users with a gateway to access third-party services without taking their assets or private keys outside the secure environment of their Ledger device*…but we’re always on a quest to build more secure features for our users. Ledger Live is the most secure way through which to buy, sell, swap, and now… Earn. 

Ledger Live’s ‘Earn’ section now allows you to stake your assets, track your rewards, and discover new staking opportunities across multiple chains, all from a single and easy-to-use dashboard while maintaining self custody of your assets.

The ‘Earn’ section provides data for all staking positions and validators for Solana (SOL), Tezos (XTZ), Ethereum (ETH), Cosmos (ATOM), Lido Token (SETH), Near (NEAR), and Cardano (ADA). We’ll also soon introduce support for additional coins and expand beyond staking.

The ‘Earn’ section features two tabs:

• The ‘Asset earning rewards’ tab allows you to track your staking rewards across different networks:

• The ‘Earn more rewards’ tab shows the list of assets that are eligible for staking, along with the estimated rewards. From there, you can get smart insights, buy and stake more assets and start earning rewards:

Explore the Internet of Value securely with Ledger

Through Ledger Live, over 1.5 million active users can buy, sell, swap, stake, and lend digital assets and explore the Internet of Value with ownership and security. With the Ledger Live app, you can also access an ever-expanding list of DApps in the Discover section, with your private keys automatically safeguarded on your Ledger device.

If you don’t have a Ledger device yet, check this article out to see which Ledger device suits your needs, or view our comparison page for a side-by-side comparison. You can also stay updated on our latest announcements and thought leadership publications through our blog.

*Buy, sell, swap, lend or any other crypto transaction services are provided by third-party service providers. Ledger provides no advice or recommendations to use any of these third-party services. 

https://www.ledger.com/blog/base-the-new-l2-incubated-by-coinbase-joins-the-ledger-live-ecosystem

The main objective of Base is to onboard the next billion users into the world of cryptocurrencies by making blockchain technology more accessible. It is designed to function both as a platform for Coinbase’s onchain products as well as an open ecosystem for developers to build their own DApps. While Base is incubated within Coinbase, the plan is to gradually transition it to a more decentralized structure.

A layer-2 network operates on top of an underlying blockchain protocol (Ethereum). It processes transactions off of the Ethereum mainnet (Layer 1), which results in a number of benefits to developers and customers, including: 

• Improved scalability and efficiency
• Increased transaction speeds  
• Reduced gas fees 
• Consistent security measures and decentralization as the mainnet (layer 1) 

Learn more about Base network here.

Create a Base account in Ledger Live

Create a Base account in Ledger Live is easy:

1. Open your Ledger Live app. 
2. Navigate into the accounts tab in Ledger Live and create a Base account. 
3. Verify and confirm the address to deposit your ETH tokens.

It’s as simple as that. 

Explore the Internet of Value securely with Ledger

Ledger Live, with over 1.5 million active users, allows you to buy, sell, swap, stake, and lend your digital assets and explore the Internet of Value with ownership and security. With the Ledger Live app, you can also access an ever-expanding list of DApps in the Discover section, with your private keys automatically safeguarded on your Ledger device.

If you don’t have a Ledger device yet, check this article out to see which Ledger device suits your needs, or view our comparison page for a side-by-side comparison. You can also stay updated on our latest announcements and thought leadership publications through our blog.

https://www.ledger.com/blog/serving-web3-at-web2-scale

Serving a large user base with reliable, consistent and low latency data is a very hard challenge for any backend team. At Ledger, we made the strategic choice to host our own blockchain core data services. By not relying on third parties, we can manage our clients’ data ourselves, ensuring that underlying processes adhere to our security guidelines and performance-oriented Service Level Objectives (SLO).

But this strategy brings its own set of challenges too.

Our first challenge is to migrate these core data-providing services away from cool and shiny noSQL tools. In this article, I will dive into why we made this difficult decision, the complexities we met and the benefits we reaped.

The goal of this article is to show the technical aspects that led us to choose PostgreSQL as our new baseline storage layer for blockchain data.

Deep dive into Blockchain Data

Blockchain data has several key features.

First, it is ever growing, and nothing is ever deleted from it. However in practice, although most of a blockchain is immutable, the youngest part of the blockchain may change due to conflicts that need to be resolved. Indeed, as the chain is a peer to peer network, several legitimate blocks may coexist temporarily. Usually, the older is deleted, resulting in what we call a reorganization. Long story short, the data is divided between an immutable cold tail and a rarely changing head state.

The issue we’re trying to solve is that whilst blockchains are great for having byzantine fault-tolerant data, they are less effective for slicing and dicing it over many axes. Namely, getting the list of operations that affected an account is very difficult. Even getting an account balance on a blockchain like bitcoin is a challenge when you don’t already have the list of transactions.

To overcome these challenges, Ledger Explorer Services index the whole blockchain.. It is a large, critical and performance-sensitive service fully written in Scala, using the cats-effect high performance runtime. We are over 10k rps on bitcoin, while maintaining a tail p95 latency under 100ms. We are also recruiting .

A little bit of history

At the beginning of our story, way before I joined the company, the Ledger data service layer was handled by an embedded Neo4j database. Each serving box was indexing its own data and served it locally, which caused a lot of issues.

Data consistency between instances was not guaranteed, and the sheer size of the state that needed to be indexed, combined by neo4j disk and ram usage, was not scalable. This problem only worsened as the company grew, making it increasingly challenging to spawn new instances.

Cassandra was then chosen as the main driver of this new setup: it is a clustered, horizontally scalable database that is on the AP side of the CAP theorem. It solves the issues related to data sharing and allows for a clear separation between the indexing, blockchain aware component and the headless API servers.

But what is the point of having the whole historical state available if we are never going to actually read from it ?

Regarding our use case, raw historical data is rarely needed because our user’s account state can be aggregated from it. This led us to challenge the existing data storage solution which is based on the Cassandra distributed database.

The volume of data we need to store per blockchain, although in the terabyte range, is not what one can call “big data”. Moreover, the part of if that will be used to answer most of the queries (a.k.a. The hot path) is even smaller. Nowadays one can easily find commodity hardware servers with more than 16TB of NVMe SSD storage. Vertical scaling is a very powerful tool, and a relational database is too.

Finally, the main issue we had with the current cassandra setup was neither the wasteful storage model nor the poorly fitted data use case, but the lack of developer friendliness. Developing a new data based feature on cassandra has proven being unnecessarily time consuming. We strived for implementing each new axis on which we need to provide data.

Given our team’s expertise in data modeling skills and SQL proficiency, PostgreSQL was the perfect candidate. This solution is Battle-tested, robust, easy to extend, making it an ideal choice.

Why we chose SQL over NoSQL:

• Reads / Writes balances: the blockchain data use case has been strongly skewed over reads rather than writes (blockchain writes very few data at a very reasonable rate, even for a blockchain like Polygon). Cassandra has the ability to absorb a very high amount of writes – the read path is actually longer than the write path.
• Indexing support: Indices are a key component of a DBMS to answer queries and new business cases or opportunities. Cassandra has limited support for indexing. Indices are only effective if the query already specifies a way to restrain the partition on which the query will run. We pay here the cost to have an arbitrary distributed database. PostgreSQL support for indices is efficient, extensible and at the edge.
• Aggregation support: Same case for aggregation; since Cassandra does not allow multi-partition aggregation and tolerates no GROUP BY clause in its query language, its support is kind of lacking. PostgreSQL proposes an extensive aggregation support, even on exotic data types like ranges and jsonb blobs.
• Data modeling: Cassandra is very, very limiting in the way data modeling is possible. A table must be created for nearly each request you want to answer, and data has to be denormalized into large rows (using fully the wide column store aspect of C* and also the fact that writers are dirt cheap). PostgreSQL allows us to leverage the relational aspect of the blockchain (calls, transactions, blocks) and spare disk space, encouraging data reuse.
• Ad-hoc queries and auditing: Being able to use the full standard of SQL and do arbitrary queries means we can explore and search for potential bug root cause or have exploratory data for future use cases. We can really use the database as an interactive and smart tool rather than a dumb storage. Doing so on Cassandra without an extensive and costly analytics compute cluster like Presto, Spark, etc. (and as we are running on bare metal servers, we don’t have access to easily spawned distributed data analysis tools like EMR).
• Storage usage: Cassandra assumption is that storage is very cheap and that the cluster can be easily extended with new machines. That means that all the limitations on both indices and aggregations must be paid for with storage. No globally efficient indices and join support means that we have to denormalize and store a copy of the whole table for each axis we want to query. PostgreSQL spares us terabytes of storage.
• Consistency: As Cassandra is a distributed, AP-oriented database (communication is made with gossiping between nodes), consistency is only eventual in terms of writes. You can tune the consistency policy of each statement for both reads and writes, but the goal of this database was never to have strong consistency. PostgreSQL has a strong story of being used for critical missions and is highly resilient. Being centralized also means that there is no network involved in the write path.
• Transactions and MVCC:
  • Transactions: Cassandra supports only lightweight transactions on DML queries. Some batching can be applied (doc) but there are numerous caveats, namely that the rows have to be in the same server (= partition) to not have horrendous performance.
  • MVCC: Cassandra supports row time stamping but the full MVCC is not guaranteed. A compaction can erase stale data and there is no way to tell C* it shouldn’t (like with e.g. a transaction in PG).
  • PostgreSQL supports a strong MVCC model that ensures a consistent read path for our users.
• Tooling: PostgreSQL has many more tools that are widely used to easily operate the database. Moreover, a tool like flyway ensures we maintain a strong versioning of the database schema. We already integrated it with our code base successfully. There is no equivalent with this level of maturity on Cassandra.
• Horizontal scalability: This is the key selling point of Cassandra.Just add more machines as your data expands. No equivalent for PostgreSQL as sharding and partitioning have to be made manually.

How we plan to scale

As we have seen, the only downside to using a Postgres setup is scaling both on reads and storage. What can we do to overcome this limitation?

The first effective tool we have is to segregate every protocol or blockchain we support into its own database, as thus can be scaled appropriately given the volume and traffic. Segmentation by business domain ensures a first layer of scaling.

By taking this concept further, we can also segment cold, historical data into temporal partition. The latest versions of Postgres have improved a lot the usability of partitioned tables, that could enable to move seamlessly data across a cluster of machines. For instance, we could use cheaper machines with less compute power to host the majority of historical data, while keeping beefy user-serving RAM-stacked behemoths to host aggregated tables and user’s latest operations.

This approach works very well in our use case because there are no cross-partition foreign keys in historical storage (everything is ultimately attached to the block). From the perspective of the main server, historical data could even be transparently accessed using partitioning and the postgres_fdw extension.

In order to help put all of this in place, we have also looked into the TimescaleDB extension. This extension adds a lot of functionalities to baseline postgres, and most of these are a perfect fit for our use cases:

• Automatic partitioning of tables based on a time like column (in our case, we adapt it by taking the blockchain height as our reference).
• Automatic, data type aware and column based compression of older chunks. This ensures a nearly perfect compression ratio by using state of the art algorithms on data that is very similar.
• Efficient time-bucket based aggregation to easily compute historical balances and market data graphs.

We are just at the beginning of experimentation regarding storage,and this unlocks a lot of use cases. Proof of concepts using a small amount of data (~10k blocks on the ethereum mainnet, so around 2 days of data) showed disk space reduction as high as 40%.

As we have seen, data volume, provided we use the right strategy, is not an issue. But how to scale with the size of our user base?

We already have a nice advantage here: we index the whole blockchain data. Thus, the storage needed won’t grow like the number of users, but like the total blockchain size. Storage and reads optimizations are totally orthogonal in their resolution.

This setup, combined with the very low write need in proportion to the read volume which needs to be served, is the dream setup for a classing leader-follower replica pattern. In order to enhance further performance and throughput, we also can place the postgres read replicas on the same machines as the API servers and take advantage of the UNIX domain sockets to skip the network round trips.

Here is an example of a data replication strategy that we could use to scale our reads. Light gray boxes represent single servers. We can see here that API pods are directly co-located with replicas of the hottest data to ensure a minimal transfer time between storage and users. Archive instances described precedently are not represented to not complicate the schema too much.

Concluding Remarks

As a long term Cassandra user, I want to emphasize that it is a great database in its design, that suits a wide variety of applications. Unfortunately, the choice that was made at Ledger to use it was made on a data use case which never materialized.

Our team productivity was impacted, and looking forward to the challenges we have to solve we chose to bite the bullet and to not fall for the sunken cost fallacy.

In many cases, your data is not big data. Managing data distribution is not a difficult task in most cases, and the tradeoffs of a full-fledged distributed database really needs to be carefully considered. The key consideration is the developer experience as it frees up valuable time to build anything else.This is the real use case we need to heavily invest in.

https://www.ledger.com/blog/ledger-announces-snz-2-of-pro-team-to-charter-adoption-creative-custody

We are glad to introduce SZN 2 of the LEDGER PRO TEAM, a collection of Web3 thought leaders, creators, artists, technologists, developers, futurists and disruptors. Our shared purpose is to educate and inspire the diverse communities that will make up the world of Web3 and digital assets.  

The LEDGER PRO TEAM are the builders, innovators and thought leaders driving the space forward. They represent the diverse audiences and communities that we build products and services for.

The 2023 LEDGER PRO TEAM includes: 

• Verbal + Yoon (AMBUSH)
• Champ Medici
• Gmoney 
• Brycent
• Dan Held

Ledger and the LEDGER PRO TEAM will collaborate throughout 2023 to educate communities on the evolving world of digital assets. Each member of the LEDGER PRO TEAM represents a specific community and area of expertise, and the diversity in skillsets, knowledge and locations across the team will allow us to educate a broad, global audience.

“The LEDGER PRO TEAM brings together the brightest cultural innovators in the Web3 space, the creators that will chart the course for mass adoption,” says Ariel Wengroff, VP of Communications at Ledger. “SZN 2 members carry the torch our SZN 1 alumni carried with distinction, as we broaden the verticals and geographies we aim to educate. We’re so proud to have these brilliant people work with us every day. This year, we’ll work with them to teach everyone the value of creative custody – we can shape a more transparent and empowered future for creators to keep their IP and their community secure.”

https://www.ledger.com/blog/building-a-best-in-class-hardware-bitcoin-multisig

What Is Multisig?

In a typical single-signature bitcoin wallet, your Ledger secures the only key needed to spend your bitcoin. This makes it easy to transfer your bitcoin around whenever you’d like, but it also means that there is a single point of failure in your bitcoin security. If someone finds your recovery phrase or gains access to your Ledger and somehow learns your PIN, they have everything they need to be able to spend your bitcoin.

In a multisig bitcoin wallet, multiple keys are used to create the bitcoin wallet, and multiple keys must be used to spend the bitcoin. The most common type of multisig wallet is created from three keys, and two out of three keys must be used to spend the bitcoin. It makes managing your security more complicated, but the trade-off is a significant improvement in security — even if someone gains access to one seed phrase or compromises one of your hardware wallets, they do not have the ability to spend your bitcoin.

Why multisig wallet is hard

Historically, hardware wallets across the industry have been optimized for single-signature custody. But as bitcoin matures, multisig is emerging as an increasingly popular option for both individuals and businesses to secure bitcoin for the long term. Unfortunately, hardware wallets generally haven’t kept up, with many continuing to provide multisig users with clunky user experiences and lower levels of on-device transaction verification.

There are three main challenges with designing a hardware wallet for multisig: 

1. Address manipulation: During the creation and signing of a multisig wallet, a malicious attacker could try to sneak in additional keys so that they have a majority control of the bitcoin, or try to send transaction change to a very obscure address that is technically part of the multisig wallet but is far removed from standard addresses and is unrecoverable without paying a ransom. 
2. Address verification: If all the public key data for the multisig wallet is not registered on the hardware wallet, verifying that you are sending change to the right address is a manual process requiring you to verify the change address on your device or through reconstructing your wallet elsewhere. Not registering the multisig wallet is also a problem when depositing to your multisig wallet. If you can’t verify on your device that you are sending bitcoin to your multisig wallet, you are trusting that your internet-connected computer is not trying to trick you into sending it to an attacker’s address. 
3. Information leak: If the multisig wallet is stored on the hardware wallet, it means that an attacker that gains access to your PIN or coerces you to unlock your hardware wallet can now immediately see that the hardware wallet is part of a multisig wallet, which reveals more information about your security set-up than is necessary.
4. Lack of account segregation: If you use the same device/seed to take part in different multisig wallets, it is no longer enough to know that you are spending from one of the wallets you are part of: you also want to know from which of them you’re spending from. The hardware wallet should check that for you.

Finally, one of the biggest challenges is that of minimizing the UX impact: if using multisig wallets is too complicated or cumbersome, users are likely to skip or sloppily apply the necessary security measures. For the majority of users, multisig is only secure if it’s easy!

Ledger to the rescue

Previously, the Ledger bitcoin application could be used for multisig wallets, but it was unable to register all of the keys that were used to build the multisig wallet, and as a result, could not verify with absolute certainty that it was signing for the right multisig wallet and verify that the change was going back to the right place. After our recent update, the Ledger is now the premier multisig hardware wallet by leveraging all of the most recent software advancements in bitcoin.

We worked closely with Unchained to validate and improve our approach to multisig, in an open-source collaboration. Unchained works day-in-day-out helping thousands of bitcoiners upgrade their bitcoin security with multisig, so they were the perfect partners to help us build the best multisig support possible.

From registering your multisig vault on the Ledger device to verifying your multisig addresses and sovereign recovery with other open-source tools, the updated bitcoin application makes Ledger best-in-class for multisig.

Verify everything – Trust Nothing

Now to get a bit technical for those curious. To make all of this work, Ledger implemented a policy registration mechanism based on a HMAC. An HMAC, or hash-based message authentication code, is a specific type of authentication code that confirms the origins and the content of certain information.

When a multisig (or, miniscript) wallet policy is registered on the device, and only after the user has inspected it and confirmed it with the secure screen, the device returns a unique HMAC for that policy.

This HMAC allows the device to confirm that the Ledger is one key in a known multisig wallet that was previously registered and validated on the secure screen. The beauty of using HMACs in this way is that the Ledger doesn’t need to store the entire multisig wallet on the device, which as mentioned above unnecessarily reveals that the Ledger is used in multisig configuration. The HMAC can be stored by the multisig coordination tool (such as Unchained) and is passed to the Ledger during bitcoin transaction signing.

This allows you to verify all information about a multisig transaction on the device and confirm that nothing about the multisig wallet was changed in the future, without trusting any internet-connected device. In other words, after the one-time registration procedure, you can receive from, and send to a multisig wallet controlled by your Ledger with a user experience that is very similar to the one you are used to for single signature transactions.

This new functionality is best experienced during multisig wallet setup with Unchained, where once the wallet is generated, Unchained will prompt you to register the wallet on the device. You’ll be given the opportunity to review all of the relevant information about the multisig wallet and confirm with your Ledger. This confirmation is then stored as an HMAC and is used moving forward to remedy all of the primary multisig problems mentioned above.

Upgrade your multisig game now

All of the new Ledger multisig functionality is available for use with Unchained and certain open-source applications such as Caravan for all Ledger models. We expect that all multisig providers and tools will implement Ledger multisig registration and device address confirmation over the next few months now that these tools are available. These features are critical for the long-term security of bitcoin, and we are happy to see teams like Unchained implement the new functionality and advance the state-of-the-art of bitcoin security.