That’s instead of Solidity, the language used to run the Ethereum Virtual Machine, which is the foundation for running smart contracts ... blockchain. “Stellar's decision to build in Rust ...

Stellar, Early Blockchain Built for Payments, Adds Smart Contracts to Take on Ethereum

The nine-year-old project, one of the earliest major blockchains, is getting a facelift to incorporate "smart contracts," that theoretically could attract new applications and users – and potentially more demand for the XLM token.

Scroll, a layer 2 to Ethereum ... on the largest smart-contracts blockchain. The blockchain makes use of zero-knowledge technology, and is compatible with the Ethereum Virtual Machine (EVM ...

Scroll Confirms Mainnet Live, as Co-Founder Predicts Speed Gains Over Ethereum

For those who are already software or web developers, Ethereum DApp development might come naturally with an understanding of blockchain technology, smart contracts, Solidity programming language ...

How to build a DApp on Ethereum

Ethereum price has generated a “death cross ... Leading cryptocurrencies continued to ease in Thursday’s Asian session amid declining DeFi liquidity, hotter than expected inflation data ...

Bitcoin, Ethereum, XRP Forecast: BTC Continues Downtrend Amid Declining DeFi Volumes

Leading cryptocurrencies continued to ease in Thursday’s Asian session amid declining DeFi liquidity ... blockchains like Ethereum. On the data front, the U.S. Producer Price Index (PPI ...

Crypto market onlookers had hoped that a spate of newly launched Ethereum futures ... helping boost its dominance in DeFi. Danksharding is meant to allow the blockchain to process 100,000 ...

Standard Chartered says Ether could reach $8,000 by 2026 as blockchain upgrades continue

Ethereum and USDT are looking at intertwined ... perfectly supporting NFTs, DApps, DeFi, smart contracts, and more. And the list continues to grow every year. So, what exactly are we looking ...

Ethereum & USDT: A partnership in crypto stability

A research paper published this week outlined a new paradigm to bring Ethereum-style smart contracts to the Bitcoin network. BitVM, as it is known, was laid out in an Oct. 9 whitepaper by Robin ...

Bitcoin Might Get Ethereum-Style Smart Contracts Under ‘BitVM’ Plan

RareSkills

rareskills

Happy Halloween, hackers 🎃! We are super excited to announce a special treat this month - the Zero Knowledge Proofs Writing Contest by RareSkills and HackerNoon. Excellent topic for the contest, right? Zero Knowledge Proof has some amazing use cases and applications in security, privacy, and web3. This is your chance to flaunt your projects, case studies, and expert knowledge to win ! Can’t wait to read the contributions of our community. $1,000 How to Enter the Zero Knowledge Proofs Contest All you need to do is: about anything relevant to Zero Knowledge Proofs. Write a story Add the and tags to your story and submit. #zero-knowledge-proofs #zkp Need some ideas to write on? Here are a few tips and tricks For devs who are interested in learning Zero Knowledge Proofs, we highly recommend this as a practical guide for programmers! You can share your learning on HackerNoon as a story for the contest. free resource on #zkp by RareSkills For more ideas and topics, check out our writing prompt for the zero proofs writing contest right now! About Sponsor is a grad school for web3 engineers seeking hands-on knowledge in web3 development. Check out the free resources by RareSkills on the HackerNoon Learn tab and learn , , and . RareSkills how to build a Zero Knowledge Proof (ZK-SNARK) from scratch in Python and Solidity Solidity Gas Optimisation Solidity Smart Contract Security The Zero Knowledge Proofs Writing Contest by RareSkills: Rules & Guidelines You must be 18+ to enter. Story content can be any original story on and . #zero-knowledge-proofs #zkp You must , as winners will be contacted via email. create a HackerNoon account Your submission should fulfill our . editorial guidelines Can I write under a pen name? Yes! You can use your real name on your HN profile or even create a persona to write under. How long will the contest run? November 1st - November 30th, 2023 Round 1: December 2023 Winner Announcement: Can I submit more than one entry to the contest? Of course you can! Each story submission shall be considered a new entry into the writing contest. Is there a word limit for the submissions? Our minimum requirement is 500 words. There’s no upper limit. You can use as many words to share your story. Can you use AI to write a story? No. That would be cheating. Only original content written by humans will be considered qualified submissions. How are the winners selected? We’ll take the top 10 story submissions, factoring in originality, relevance, reads, and reading time. Those ten stories will be voted on by HackerNoon staff, and the top story with the most votes will win. We are waiting for your submissions! All the best, hackers! Visit to keep updated with the new and upcoming writing contests. contests.hackernoon.com

The Zero Knowledge Proofs Writing Contest by RareSkills 

রেয়ার স্কিলস দ্বারা জিরো নলেজ প্রুফ রাইটিং কনটেস্ট

Der Zero Knowledge Proofs-Schreibwettbewerb von RareSkills

El concurso de redacción de pruebas de conocimiento cero de RareSkills

Le concours de rédaction d'épreuves Zero Knowledge par RareSkills

रेयरस्किल्स द्वारा शून्य ज्ञान प्रमाण लेखन प्रतियोगिता

RareSkills によるゼロ知識証明ライティング コンテスト

RareSkills의 영지식 증명 쓰기 콘테스트

O Concurso de Redação de Provas de Conhecimento Zero da RareSkills

Конкурс написания доказательств с нулевым разглашением от RareSkills

RareSkills'in Sıfır Bilgi Kanıtı Yazma Yarışması

Cuộc thi viết bằng chứng kiến thức Zero của RareSkills

RareSkills 零知识证明写作比赛

The Tech Behind Tornado Cash (Line by Line for Programmers)

A smart contract audit is a review by blockchain security experts to ensure that users will not lose funds due to a malfunction or security vulnerability. Furthermore, an audit tries to anticipate unexpected and undesirable smart contract behavior before the contract is deployed. Navigating this field is tricky. There are dozens of audit firms, and getting quotes from several of them takes time, and it is hard to know if you are getting a fair price or not. This article will help serve as a starting point for navigating the task of getting a smart contract audit. References to auditing firms in this article should not be construed as an endorsement. There is no official standard for a smart contract audit And there probably won’t be one for the foreseeable future with how fast the industry moves. The term “smart contract audit” is an evolution of industry lingo, it does not have a rigorous definition, and it can mean different things to different people. For those coming from industries where are the norm, smart contract auditing will seem like the wild west (and frankly, that would be an accurate assessment). ISO standards Although some are well known, others are emergent properties of complex systems and are hard to detect systematically. smart contract vulnerabilities Standards are characteristic of mature markets, and as a whole is not a mature market. web3 It is a bit of a conflation of terms to call smart contract audits “audits.” In the field of accounting, an “audit” has a very rigorous definition; this is not the case in blockchain engineering. What is called an “audit” in the blockchain is a security review by a team of experts. What makes this even more confusing is that there is no formal definition or certification for what makes someone an auditor or security expert in smart contracts. Yes, there are companies selling certifications, but these certifications hold no weight in the industry. As you can expect, there are several enterprising individuals capitalizing on the confusion to sell expertise they don’t have — as there is no established way to measure expertise. Caveat emptor. All that said, it is widely agreed in the industry that saying “this smart contract has been audited” means “a group of security experts was paid to review this codebase and find issues.” Since there is no formal definition for expertise, industry reputation is often used as a proxy. Three main types of auditors Smart Contract Audit Companies These are firms that specialize in security research. Some only audit smart contracts, while others audit smart contracts and traditional computer applications. You can think of this as an agency composed of security researchers. Until recently, this was the standard way to get a smart contract audit. If you do a Google search for smart contract auditing companies, these are the sort of results you will typically get. Independent security researchers Rather than join a company, some security researchers work for themselves. They are a little harder to find as they have much smaller marketing budgets compared to agencies, but because they have less overhead, they can often provide better prices. One drawback is that a firm is able to have several auditors review your code, whereas an independent auditor will only have one reviewer. But for smaller or less complicated codebases, this might be more cost-effective. Competitive audits Recently, a couple platforms ( , ) have popped up where companies requesting an audit publish their source code on the platform along with a monetary prize pool, and then independent contestants try to find bugs and vulnerabilities. Sherlock DeFi Code4rena The more bugs a contestant finds, the more money they will earn, but if another contestant finds the same bug, then the payout is diluted between the two. For well-understood bugs, the payout can be diluted considerably. Earnings for auditors in this format are quite sub-par. Contestants can rarely expect to make much more than $1,000 per contest despite putting in considerable effort. The primary incentive for participants is to prove their abilities so they can get a job at a traditional audit firm or attract business as a solo auditor (independent researcher). There are also no guarantees about the quality of the people participating in the contest, as anyone can participate. However, these platforms can be very educational for new auditors. Because the format encourages an intense focus on finding bugs, then gives feedback on what bugs were missed, they can provide a relatively tight feedback loop which helps speed up learning. In fact, we guide some of our solidity training to participate in these contests for educational purposes. The best auditors don’t spend a significant amount of time in contests, as they earn far more money working for themselves or for a firm. So keep in mind that someone doing well in an auditing contest may simply mean that they did not face significant competition for the contests they participated in. There is also an element of luck where a single contest makes up a significant portion of an auditor’s public earnings. However, this format get far more eyes on the code than other audit formats, and audit contests have caught bugs missed by other auditors. They also serve as a channel for companies to subtly market their protocols to the developer and auditor communities, so they are a valuable contribution to the ecosystem. Bonus: Informal code roasting Some developer discord groups will review your code for free (out of the desire to be helpful, so please don’t abuse others’ generosity). If you have a small and simple codebase, sometimes getting a few experts to donate their time may be the most cost-effective route for you. It would be extremely disingenuous for such a review to be called an “audit,” but if it is the only option available, it’s certainly better than no review at all. Things to watch out for in smart contract audits Look at past audits from the firm Some auditors use a rigid checklist for a list of smart contract vulnerabilities and check if the issue is present or not. This is good as a first pass, but many bugs are application-specific (as we note in that article). You want to make sure the auditor will consider the nuances and business requirements of your application. By looking at their past audits, you can see if they mechanically go against a list or dive deep into the specifics of your application. An auditor not supplying past audits is generally a red flag. Auditor specialization If your project uses exotic tokenomics or , then you will want to make sure that your selected auditor has experience with that. Similarly, if you are building a dapp on a non-evm compatible chain like , then you’ll want an auditor experienced with that blockchain. DeFi Zero Knowledge Proofs Solana Minimum cost Some audit firms will not bother with small codebases like an ERC20 token or a basic NFT because they won’t make enough money to pay for the sales call and account management. Rubber stamp auditors Because there is no formal or accepted definition for an audit, some firms have popped up that produce what is derisively known as “rubber stamp audits.” These firms provide audit reports simply because the buyer wanted an audit so they could tell their customers, “look, we’ve been audited!” Not every protocol intentionally gets rubber stamp audits; they may simply have chosen the auditor unaware that they are rubber stamp auditors. How reliable are smart contract audits? Even if a smart contract is audited, it can still get hacked afterward; this is not a rare occurrence. has a that tracks smart contract hacks by the amount of money lost. It’s easy to see most of the hacked protocols were not audited at all. Rekt.news leaderboard However, some of the protocols did have audits, some more than one, that the auditors still missed. In some cases, this can be because the auditors were incompetent or didn’t try hard enough, but in general, it is not possible to guarantee a codebase is free of bugs. The good news is some vulnerabilities don’t only get missed by auditors; they get missed by hackers too. Some smart contracts had gone on for months with a live vulnerability before they got patched. A decent audit will make sure the “low-hanging fruit” for hackers is eliminated. Should I get multiple audits? This is standard practice with well-funded DeFi protocols that intend to hold a lot of money; having three or more audit firms review the code is quite normal. What one auditor misses, another may catch, and vice versa. Similarly, one auditor may notice a vulnerability, and the developers may patch that vulnerability while introducing a different one. Typical Workflow of getting an audit You’ll reach out to various firms asking for quotes, and you’ll coordinate based on their availability and your launch dates. 1. Get quotes You should be in a code freeze when you go to audit. If the auditors are reviewing a different codebase from the one you will launch to prod, you are probably wasting money! 2. Audit begins Most audit reports (that don’t follow a fixed checklist) will return a list of findings categorized as Critical, High, Medium, Low, Informational, and Gas Optimization. These are explained in the following section. An audit can be as short as a few days to as long as a few months, depending on the scope of the project. 3. Audit report Depending on the agreement, the auditor will review the changes made by the developers and ensure the fix actually addresses the bug. The number of revision reviews considered acceptable depends on the auditor. 4. Review fixes Auditors generally publish their report if the customer permits (and customers usually want the audit to be public to show they’ve been audited). 5. Publish Report Audit Finding Severity Most audit reports group security findings into severity: Critical High Medium Low Informational Gas Optimization Not all firms use the same labels. As we noted, with the lack of universal standards, there isn’t a uniform definition for what is considered a “high” or “medium” vulnerability. Some auditors disagree about the appropriate rating to assign the same bug, but here are some factors auditors use to assign severity: Worst case outcome. All of the funds getting stolen is catastrophic. Bugs where a hacker cannot steal funds but users aren’t adequately protected from shooting themselves in the foot would be labeled with low severity. Number of users affected. The entire protocol losing money is more severe than an individual user losing money. Incentive to conduct the attack. If an attacker needs to spend more capital to conduct an attack than they would gain for carrying it out, then the severity is reduced. This is still a vulnerability because the attacker could have a non-economic motive to carry out an attack (showing off, personal vendetta, etc). Obscurity of the attack. If the vulnerability is something like missing an access control, then an unsophisticated attacker can carry out the attack. If the weakness depends on a deep understanding of a sophisticated tokenomics mechanism using advanced mathematics, then it is less likely the attacker will find the issue. Some auditors combine the last two factors into one: the likelihood of an attack. Under this model, they use the following table to assign severity: Critical vs High vs Medium Some auditors make a distinction between critical vulnerabilities and high vulnerabilities, and other auditors group critical vulnerabilities with high vulnerabilities. In either case, these are considered to be extremely serious bugs! For those that make a distinction, Critical may mean the entire protocol is severely affected, whereas a High means individual users may be severely affected. Medium severity issues usually mean issues which can be damaging but unlikely to occur. Informational Some auditors will point out issues, such as not adhering to the Solidity style guide or having variable and function names that are misspelled or misleading. These are not security vulnerabilities but could cause confusion down the road. Not all auditors point out informational issues. Gas Optimization Some auditors will suggest ways to improve the gas efficiency of certain codes. These are not security related, but they will certainly improve user experience. How much does it cost to audit a smart contract? Estimates based on public information If you look on Fiverr, you’ll find some services to audit smart contracts for low prices, but would you really want to depend on that kind of service for something this critical? Because contracts usually have non-disclosure agreements, rates can be hard to determine, but here is some public information. Competitive audit platforms advertise the reward pool, and of course, this money is coming from the customer paying for the audit. Here you can see prize pools as low as 5k and sometimes up to hundreds of thousands of dollars for very large projects. Of course, the people running the contest expect a fee for running the platform, so the actual cost will be higher. 1. Reward pools for competitive audits The auditing firm Spearbit published the at which they pay their auditors (who are contractors, not employees), so one can infer how much an audit will cost (not including the operations and profit margin) based on this. The pay per auditor is 3k-20k per week depending on seniority. Keep in mind this is not a full time job, but per-engagement. 2. Contractor salaries rates Another data point we have is independent auditors who have been public about earnings. One claims to earn on good months, taking on about four audits per month, another claimed with five audits. This is on the high end of what an independent auditor can expect to make, but it’s not outside the realm of possibility; staff engineers in top Silicon Valley companies . 3. Independent auditors $40k per month $50,000 in one month earn more than that How auditors generate quotes There is no standard pricing model, but here are some practices auditors use to determine the price they quote. Dollars per lines of code A common pricing model is $ / lines of code. This could cost between a few dollars to tens of dollars per line. Size and complexity Other auditors use a combination of size and complexity. A 1,000 line NFT is considerably simpler than a 1,000 line mathematics library. The auditing firm will make a subjective judgement based on the combination of these factors. Similarity to existing protocols Some auditors will give a discount if the project to be audited is forked, or very similar, to an established project as they can leverage past audits to determine if your project learned from past mistakes. Also, the total number of lines that have not been reviewed is a small percentage of the project. Different auditors will have a different threshold for what constitutes "similar" to established projects. Pay per vulnerability This model is common among independent auditors. The security researcher is paid a small downpayment and receives a payout for each bug found with a higher price for higher severity issues. This has the advantage of incentivizing the auditor to search harder, but it can also incentivize exaggerating the severity of bugs. Why are audits so expensive? Compared to other highly specialized knowledge workers, like lawyers (the best of whom can pull in over ), smart contract audits are not prohibitively expensive, but they can be a significant burden for small companies. one million dollars per month Becoming a smart contract auditor isn’t easy. Generally, the skill level required is comparable to trying to get a highly competitive job in Silicon Valley, which means starting salaries are going to easily be in six-figure territory. An auditing firm needs to charge a significant margin on top of those salaries to stay profitable, so it shouldn’t be surprising that audits cost tens of thousands of dollars, if not hundreds of thousands of dollars. Want help from RareSkills? RareSkills is not an auditing firm, but many of our are professional auditors, and we do engage in security research. We have an insider view of which firms are reputable and which are not. Feel free to and tell us about your needs, and we will refer you to the right resource based on your situation. instructors contact us If you are seeking to train your engineers in how to develop secure smart contracts, then our industry-leading for professional engineers may be of interest to you. smart contract bootcamp Also published . here

Getting a Smart Contract Audit: Everything You Need to Know

Obtener una auditoría de contrato inteligente: todo lo que necesita saber

Obtenir un audit de contrat intelligent : tout ce que vous devez savoir

स्मार्ट कॉन्ट्रैक्ट ऑडिट प्राप्त करना: वह सब कुछ जो आपको जानना आवश्यक है

スマートコントラクト監査の取得: 知っておくべきことすべて

Obtendo uma auditoria de contrato inteligente: tudo o que você precisa saber

Kiểm tra hợp đồng thông minh: Mọi thứ bạn cần biết

进行智能合约审核：您需要了解的一切

Smart Contract Security in Solidity

সলিডিটিতে স্মার্ট কন্ট্রাক্ট সিকিউরিটি

Intelligente Vertragssicherheit in Solidität

Una encuesta de 2023 sobre seguridad de contratos inteligentes para la solidez

Une enquête 2023 sur la sécurité des contrats intelligents pour la solidité

सॉलिडिटी के लिए स्मार्ट कॉन्ट्रैक्ट सिक्योरिटी पर 2023 का सर्वे

Solidity のスマート コントラクト セキュリティに関する 2023 年の調査

Solidity의 스마트 계약 보안

Uma pesquisa de 2023 sobre segurança de contratos inteligentes para solidez

Sağlamlıkta Akıllı Sözleşme Güvenliği

Khảo sát năm 2023 về bảo mật hợp đồng thông minh cho sự vững chắc

2023 年 Solidity 智能合约安全性调查

Solidity RSA signatures for aidrops and presales: Beating ECDSA and Merkle Trees in Gas Efficiency By and Suthan Somadeva Michael Burke Introduction Creating a contract that gives certain addresses permissions goes by several names: airdrops, presale, whitelist, allowlist, and so forth. But the essence of the idea is there is a set of addresses that have special permission to buy a high-demand token for a desirable price (sometimes free). There are three established solutions for this: mappings, Merkle trees, and ECDSA signatures. The relative merits of these approaches have already been , so we will summarize the results: discussed elsewhere ECDSA Signature Verification (Gas: 29,293) using Merkle proofs (Gas: 30,517, 128 addresses) A mapping presale works when the seller enters the addresses of the customers into a mapping that goes from address to boolean to note if the address is privileged or not. The mapping is set to false after the buyer completes the transaction. This ensures only addresses that are marked true can make a purchase. This is very gas efficient for the buyer, but the seller could allow-listing thousands of addresses, (it will cost at least 22,100 gas to add an address to the allowlist). spend millions of gas Because of this, Merkle Trees and ECDSA signatures (using the precompile , or better yet, the published by OpenZeppelin), are often preferred to mappings. The gas cost (for the buyer) of executing the ECDSA signature verification is 29,293 gas. This includes the 21,000 to initiate the transaction, so the ECDSA cost is 8,293. Note that this includes reading the signing address from storage, but this cost is necessary or we won’t be able to invalidate signatures. ecerecover more secure wrapper around it Merkle Trees vary in cost based on tree size (larger trees require larger Merkle proofs), but if over 1,000 addresses are in the Merkle tree, it will cost at least 32,000 gas (or more) to verify the address. This cost is clearly inferior to ECDSA. The goal, then, is to beat ECDSA which costs 8,293 gas. To keep solutions apples-to-apples, the alternative solution must: Be able to nullify allow-listed addresses. Merkle trees can change their root, ECDSA , can change their signing address, and mappings can set the value to false. Not impose a substantial cost burden on the seller the way mappings do Cost less than 8,200 gas for the buyer (including a storage load) Not be compromised on security Prerequisites To understand the proposed methodology, the reader should be familiar with the following subjects: Precompiled smart contracts ( , ) recommended reading stackexchange Metamorphic contracts ( , ) introduction recommended reading Access lists ( ) recommended reading How to use digital signatures and their appropriate use cases in blockchain applications How gas cost is computed, especially as it relates to calldata, opcodes, storage, and memory usage. The RSA Algorithm If we want to substantially beat ECDSA, we need to find a different cryptographic algorithm that allows for the proof of set membership. ECDSA is actually the newer, cooler version of the original digital signature algorithm, RSA. ECDSA relies on discrete logarithms over elliptic curves being hard (hence the name – elliptic curve digital signature algorithm). RSA (named after its authors, Rivest, Shamir, Adleman) relies on large integers being hard to factor. In terms of age, RSA was published in the 1970s, but ECDSA became a formal specification in the early 2000s. We will not explain RSA in detail here, but some prerequisites are in order. The signer picks two large prime numbers p and q, and multiplies them together to produce n. This is the first part of the public key. Second, the signer picks a small prime (can be hardcoded to for our usecase), and publishes the pair as the public key. Behind the scenes, the signer computes n e 3 (n, e) t = (p - 1) * (q - 1)
d = t^(-1) % n The number is the private key. If an adversary could decompose into and , then computing would be trivial. But it is known that . To sign a message, the signer hashes the message to get and raises to the power . That is, d n p q d integer factorization is hard m h h d s = h(m) ^ d % n The signer then publishes as the message and signature. (m, s) The verifier then hashes and raises it to the power . Remember, and are the public key. If and only if m e mod n e n s == s ^ e % n then the signature is valid for the public key . Note that if is extremely large, then the probability that by random chance is vanishingly small. If the equality checks out, then we know the signature is valid for the public key. (n, e) n s == s ^ e % n To do this in Ethereum, we would simply sign an address as s = buyerAddress ^ d % n and the smart contract would verify msg.sender == s ^ e % n Using only 256 bits is unsafe We say “factoring integers is hard” but clearly this implies that the number must be large enough. For example, 33 is composed of two prime numbers and is trivial to decompose. Thankfully, we have real-world benchmarks of what the state-of-the-art can accomplish in the . RSA Factoring Challenge To clarify, the number of “bits” refers to the size of the public key. Therefore, when we say “RSA 2048”, this means the number n, the modulus, has 2048 bits. When comparing key sizes, it’s important to remember that each additional bit doubles the size of the number. So 700 bits is exponentially more secure than 350 bits, not twice as secure. The largest key to be cracked (factored) so far had 829 bits, and it required a modern supercomputer to do it. The team utilized approximately 2700 CPU core-years, using a 2.1 GHz Intel Xeon Gold 6130 CPU. The cheapest 16 core CPU on AWS costs $0.40 cents per hour, so the cost to crack this key is in the order of $9.4 million dollars. Even assuming generous discounts from the cloud provider, the cost is in the millions. Modular arithmetic with more than 256 bits in Solidity Ethereum only supports 32-byte data types, so by default, we cannot carry out s ^ e % n Thankfully, the Ethereum blockchain added a precompiled contract in specifically to support modular arithmetic. To use it, the base, exponent, and modulus must be loaded into memory in abi encoded format. Then the contract living at address is invoked. EIP 198 0x05 Storing the public key becomes a bit of an issue if you use a secure amount of bits. If the key size is 1024 bits, that necessitates 4 storage slots. To read the public key out of storage would be four operations, for a total of 8,400 gas. This by itself is already less efficient than the ECDSA solution benchmarked above. SLOAD If we use immutable variables, this cost is largely eliminated, but this creates a weakness if we cannot retroactively remove someone from the presale. In traditional ECDSA or Merkle Trees, we would just replace the signing address or the Merkle Root. This isn’t possible if we use an immutable variable. However, storing the public key in the bytecode instead of storage is the key idea. Reading an external contract’s bytecode ( ) costs 2,600 gas, which is far less than the 8,400 gas of reading each part of the public key in four pieces. EXTCODECOPY To invalidate a public key, we could simply create a new contract, and update a storage variable to point to the new address. But that adds back an additional 2,100 gas. It turns out, it is possible to store the external contract’s address (whose bytecode stores the public key) in an immutable variable, but still invalidate the public key by mutating the external smart contract’s bytecode. Invalidating the public key with the metamorphic contract pattern A smart contract is created by loading the deployment bytecode into memory, then returning the range of the bytecode which contains the runtime code. See more . here When a smart contract is created with the command, the address of the contract can be predicted in advance. The address is calculated from the combination of salt, the deployer, and the initialization bytecode. If the contract self-destructs, then a new contract at the same address can be deployed. create2 Note that the address is a function of the initialization code, not the deployed code. It is possible to deploy different bytecode by having the initialization code load a different runtime code. By self-destructing and redeploying with the same initialization code but a different deployment code, the bytecode of the contract can mutate. Therefore, we can have a smart contract whose first bytes are for self-destructing under a certain condition, but the rest of the bytes are just the RSA public key. k Because the address is determined in advance, we can store the address of this metamorphic contract in an immutable variable. We can from that address when we need the public key. To replace the public key, we instruct the contract to , then deploy a new contract to that address. EXTCODECOPY selfdestruct Saving an additional 100 gas with access lists added a new type of transaction that allows the user to specify in advance which addresses and storage slots will be accessed. This allows the nodes to prefetch those values from storage, thus speeding up execution time. Using an access list transaction when calling an external contract can save 100 gas. Note that this saving does not apply when a smart contract accesses its own storage variable. Because this RSA presale airdrop design relies on an external contract to store the public key, then using an access list is appropriate. EIP 2930 Benchmarks: Gas cost vs key size Most of the gas cost comes from having very large calldata as a result of large signatures. If the key size is set to 1024 bits, then the call data will be 128 bytes. Each byte costs 16 gas, so the total gas cost just to have calldata that large is 2,048 gas. Compared to most other use cases, ours uses a considerable amount of memory, and Ethereum charges for this. Why this saves gas relative to ECDSA The benchmarks make it clear that the larger the key (and hence the signature), the larger the gas cost. Our design exploits the fact that the precompile assigns a low price to raise numbers to low power. The cost of executing the precompiled contract under those conditions at is only a few hundred gas compared to thousands for executing the precompile for ECDSA. 0x05 Choosing a key size Although a key with 829 bits has been factored in, it requires a modern supercomputer to do so. For applications such as airdropping lower-value tokens or putting NFTs on a presale, an attacker does not have the incentive to spend six figures to a million dollars to factor a public key and obtain an NFT in a presale. The most expensive Ethereum tokens at this time of writing ( and ) cost approximately $100,000 a piece, so for the vast majority of applications, it is not economical for an attacker to try to factor the public key. Fidenza Bored Ape Yacht Club Remember, each bit doubles the difficulty of factoring the integer, so as of 2022, most low-value token presales are probably safe with 896 bits. In this case, saving users over 2,500 gas compared to ECDSA is compelling. Key Size Benchmarks This was conducted with Solidity compiler version 0.8.17 with the optimizer set to 1 million RSA-896 (Gas: 27,040) RSA-960 (Gas: 27,115) RSA-1024 (Gas: 27,311) RSA-2048 (Gas: 29,901) Conclusion We present a novel method for assigning addresses to a presale or airdrop that is more efficient than the known solutions today. By combining the modular exponentiation precompile with the metamorphic contract pattern and the access list transaction, we can validate secure RSA signatures on-chain in a gas-efficient manner. Our work is only a proof of concept at this stage. Developers are advised to use caution using the code in production. This project was created by and as part of the . The code implementation and unit tests are on . Suthan Somadeva Michael Burke RareSkills Solidity Bootcamp github Also published here.

Using Solidity RSA Signatures for Presales and Airdrops

An ethereum address is the last 20 bytes of the keccack256 of the public key. The public key algorithm is secp256k1, the same used in bitcoin. Because it is an elliptic curve algorithm, the public key is an (x, y) pair corresponds to a point on the elliptic curve. Generate the Elliptic Curve Public Key. The public key is the concatenation of x and y, and that is what we take the hash of. The code is provided below. from ecpy.curves import Curve
from ecpy.keys import ECPublicKey, ECPrivateKey
from sha3 import keccak_256

private_key = 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

cv = Curve.get_curve('secp256k1')
pv_key = ECPrivateKey(private_key, cv)
pu_key = pv_key.get_public_key()

# equivalent alternative for illustration:
# concat_x_y = bytes.fromhex(hex(pu_key.W.x)[2:] + hex(pu_key.W.y)[2:])

concat_x_y = pu_key.W.x.to_bytes(32, byteorder='big') + pu_key.W.y.to_bytes(32, byteorder='big')
eth_addr = '0x' + keccak_256(concat_x_y).digest()[-20:].hex()

print('private key: ', hex(private_key))
print('eth_address: ', eth_addr) The ecpy library is here . This library implements the elliptic curve math in python, so it won't be as fast as a wrapper around the bitcoin C implementation, which is used by the library. https://github.com/cslashm/ECPy coincurve However, the python implementation allows you to see step by step the elliptic curve math used to derive the public key. You can use this code to generate an ethereum vanity address with brute force, but be mindful that if your source of randomness is not secure or has insufficient randomness, you may fall victim to a hack similar to . this Generate private key with python and coin flips or dice You can generate an Ethereum address from a private key yourself by flipping a coin 256 times and writing to a string a 1 if it’s heads and 0 if it is tails. Let’s say you get the following outcome result = b'1100001011001101010001001100101000001111101101111011001000110001101100011101101011010001011000101111100110010101001001101110111011001000100001010101111100001100100110010010111110110100000010011111100000110101001110000101100101011111001101010001100001000' You can convert that to a private key using the following python code # 2 means base 2 for binary

private_key = hex(int(result, 2))

# private key is 0x1859a89941f6f646363b5a2c5f32a4ddd910abe19325f6813f06a70b2be6a308 Then, plug that private key into the code from the above section and you’ve generated your address with your own randomness. The same thing can be accomplished faster by rolling a 16-sided dice 64 times and writing out the hex string that is produced character by character. Be mindful that most dice don't have a representation for the number zero, so you'll have to subtract 1 from each result. If you only have traditional six-sided, you can write out a string in base 6 (don't forget to subtract 1 from each roll) and do a base conversion to binary. You'll need to keep rolling until you have at least 256 bits for your private key. If you are particularly paranoid about randomness, you can use casino grade dice. Be cautious using the built-in random number library for Python. It's not intended to be cryptographically secure. We recommend familiarizing yourself with if you are new to the topic. cryptographically secure randomness Generally, you cannot initialize a hardware wallet using this method because the 24 word recovery phrase they use is not the same thing as a private key used to sign transactions. The 24 word recovery phrase is used to derive multiple private keys for different types of crypto the wallet holds. Math: About secp256k1: Public Key from Private Key There is already a lot of material online describing what curve addition looks like , so we will describe it at a lower level here. visually The shape of the Curve Secp256k1 defines the shape of the elliptic curve y^2 = x^3 + y (mod p) where p is the prime number 115792089237316195423570985008687907853269984665640564039457584007908834671663 or 2^256 – 2^32 – 977 The prime should not be confused with the of the curve. Not every value 0 < n < p satisfies the equation above. However, operations on the curve are guaranteed to be . That is, if two valid points are added or multiplied, the result will be a valid number on the curve. p order closed The starting point The other important parameter in secp256k1 is the starting point G. Since G is a point on the elliptic curve, it is 2-dimensional and has the parameters x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
y = 32670510020758816978083085130507043184471273380659243275938904335757337482424 To see G is a valid point, we can plug the numbers into python x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
p = 115792089237316195423570985008687907853269984665640564039457584007908834671663

assert pow(y, 2, p) == (pow(x, 3) + 7) % p To create a public / private key pair, a random number is created (this is the secret key). The point G is added to itself times and the new point (x, y) is the public key. It is not feasible to derive from G. s s s Adding G to itself s times is the same as multiplying s * G. In fact, we can see this operation at a lower level in by stripping away some of the abstractions the library is providing. from ecpy.curves import Curve
from sha3 import keccak_256

private_key = 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

cv     = Curve.get_curve('secp256k1')
pu_key = private_key * cv.generator # just multiplying the private key by generator point (EC multiplication)

concat_x_y = pu_key.x.to_bytes(32, byteorder='big') + pu_key.y.to_bytes(32, byteorder='big')
eth_addr = '0x' + keccak_256(concat_x_y).digest()[-20:].hex()

print('private key: ', hex(private_key))
print('eth_address: ', eth_addr) The public key is simply the private key multiplied by the point G on the secp256k1 elliptic curve. That's it. Learn More Check out our advanced today and become a blockchain developer who knows the hard stuff other coders don't. blockchain bootcamp Also published . here

How to Generate an Ethereum Address From Private Key Using Python

Cómo generar una dirección de Ethereum a partir de una clave privada usando Python

Comment générer une adresse Ethereum à partir d'une clé privée à l'aide de Python

पायथन का उपयोग करके निजी कुंजी से एथेरियम पता कैसे उत्पन्न करें

Python を使用して秘密キーからイーサリアム アドレスを生成する方法

Como gerar um endereço Ethereum a partir de uma chave privada usando Python

Cách tạo địa chỉ Ethereum từ khóa riêng bằng Python

如何使用 Python 从私钥生成以太坊地址

Solidity events Solidity events are the closest thing to a “print” or “console.log” statement in Ethereum. We will explain how they work and when to use them. We will also go into a lot of technical details often omitted in other resources. Here is a minimal example to emit a solidity event. contract ExampleContract {

  // We will explain the significance of the indexed parameter later.
  event ExampleEvent(address indexed sender, uint256 someValue);

  function exampleFunction(uint256 someValue) public {
    emit ExampleEvent(sender, someValue);
  }
} Perhaps the most well-known events are those emitted by tokens when they are transferred. The sender, receiver, and amount are recorded in an event. ERC20 emit Transfer(from, to, amount); Isn’t this redundant? We can already look through the past transactions to see the transfers, and then we could look into the transaction calldata to see the same information. This is correct, one could delete events and have no effect on the business logic of the smart contract. However, this would not be an efficient way to look at history. Table of contents Solidity events Retrieving transactions faster Listening to events Solidity-indexed events vs non-indexed events Solidity events best practices Events cannot be used in functions How many arguments can an event take? Variable names in events are option but recommended Events can be inherited through parent contracts and interfaces Event selector Anonymous events Advanced topics about events Gas cost to emit solidity event Conclusion Retrieving transactions faster The Ethereum client does not have an API for listing transactions by “type,” for example “all transfer transactions of an ERC20.“ Here are your options if you want to query transactions: getTransaction getTransactionFromBlock API can only tell you what transactions occurred on a particular block, it cannot target a smart contract address multiple blocks. getTransactionFromBlock can only inspect transactions you know the transaction hash for. getTransaction Events on the other hand can be retrieved much more easily. Here are the Ethereum client options: events events.allEvents getPastEvents Each of these requires specifying the smart contract address that the querier wishes to examine and returns a subset (or all) of the events a smart contract emitted according to the query parameters specified. Here is the key insight for why you would use Events to track transactions rather than transactions themselves: Ethereum does not provide a mechanism to get all transactions for a smart contract, but it does provide a mechanism for getting all events from a smart contract. Why is this? Making events quickly retrievable requires additional storage overhead. If Ethereum did this for every transaction, this would make the chain considerably larger. With events, solidity programmers can be selective about what kind of information is worth paying the additional storage overhead for, to enable quick off-chain retrieval. Listening to events Here is an example of using the API described above. In this code, the client subscribes to events from a smart contract. These examples are all in Javascript. Example 1: Listening to ERC20 Transfer events. This code triggers a callback every time an ERC20 token emits a transfer Event. const { ethers } = require("ethers");

// const provider = your provider

const abi = [
  "event Transfer(address indexed from, address indexed to, uint256 value)"
];

const tokenAddress = "0x...";
const contract = new ethers.Contract(tokenAddress, abi, provider);

contract.on("Transfer", (from, to, value, event) => {
  console.log(`Transfer event detected: from=${from}, to=${to}, value=${value}`);
}); Example 2: Filtering an ERC20 approval for a specific address If we want to look at events retroactively, we can use the following code. In this example, we look to the past for Approval transactions in an ERC20 token. const ethers = require('ethers');

const tokenAddress = '0x...';

const filterAddress = '0x...';

const tokenAbi = [
  {
    "anonymous": false,
    "inputs": [
      {
        "indexed": true,
        "name": "from",
        "type": "address"
      },
      {
        "indexed": true,
        "name": "to",
        "type": "address"
      },
      {
        "indexed": false,
        "name": "value",
        "type": "uint256"
      }
    ],
    "name": "Transfer",
    "type": "event"
  }
];

const tokenContract = new ethers.Contract(tokenAddress, tokenAbi, provider);

// this line filters for Approvals for a particular address.
const filter = tokenContract.filters.Approval(filterAddress, null, null);

tokenContract.queryFilter(filter).then((events) => {
  console.log(events);
}); If you wanted to look for a trade between two particular known addresses (if such a transaction exists), the ethers.js. code would be as follows: tokenContract.filters.Transfer(address1, address2, null); Here is a similar example in instead of ethers.js. Note that the and query parameters are added (to signify we only care about events between these blocks), and we will demonstrate the ability to listen to multiple addresses being the sender. The addresses are combined with the "OR" condition. web3.js fromBlock toBlock const Web3 = require('web3');

const web3 = new Web3('https://rpc-endpoint');
const contractAddress = '0x...'; // The address of the ERC20 contract
const contractAbi = [
  {
    "anonymous": false,
    "inputs": [
      {
        "indexed": true,
        "name": "from",
        "type": "address"
      },
      {
        "indexed": true,
        "name": "to",
        "type": "address"
      },
      {
        "indexed": false,
        "name": "value",
        "type": "uint256"
      }
    ],
    "name": "Transfer",
    "type": "event"
  }
];
const contract = new web3.eth.Contract(contractAbi, contractAddress);

const senderAddressesToWatch = ['0x...', '0x...', '0x...']; // The addresses to watch for transfers from

const filter = {
  fromBlock: 0,
  toBlock: 'latest',
  topics: [
    web3.utils.sha3('Transfer(address,address,uint256)'),
    null,
    senderAddressesToWatch,
  ]
};

contract.getPastEvents('Transfer', {
  filter: filter,
  fromBlock: 0,
  toBlock: 'latest',
}, (error, events) => {
  if (!error) {
    console.log(events);
  }
}); Solidity-indexed events vs non-indexed events The example above works because the Approve (and Transfer) event in ERC20 sets the sender to be indexed. Here is the ERC20 Approval event declaration in Solidity. event Approval(address indexed owner, address indexed spender, uint256 value); If the “owner” argument was not indexed, the javascript code earlier would silently fail. The implication here is that you cannot filter for ERC20 events that have a specific (token amount) for the transfer, because that is not indexed. You must pull in all the events and filter them javascript side; it cannot be done in the Ethereum client. value An indexed argument for an event declaration is called a . topic Solidity events best practices The generally accepted best practice for events is to log them whenever a potentially consequential state change happens. Some examples include: Changing the owner of the contract Moving ether Conducting a trade Not every state change requires an event. The question the Solidity developers should ask themselves is “would someone have an interest in retrieving or discovering this transaction quickly?” Index the right event parameters This will requires some subjective judgement. Remember, an unindexed parameter cannot be searched for directly, but still might be useful data when accompanied by an indexed parameter. A good way to get an intuition for this is to look at how established codebases design their events Gnosis Safe Uniswap ERC20 Specification ERC721 Specification As a general rule of thumb, cryptocurrency amounts should not be indexed, and an address should be, but this rule should not be applied blindly. Indexes only allow you to quickly get exact values, not a range of values. Avoid redundant events An example of this would be adding an event when tokens are minted because underlying libraries already emit this event. Events cannot be used in view functions Events are state changing; they alter the state of the blockchain by storing the log. Therefore, they cannot be used in view (or pure) functions. Events are not as useful for debugging the way console.log and print are in other languages; because events themselves are state-changing, they are not emitted if a transaction reverts. How many arguments can an event take? For unindexed arguments, there is no intrinsic limit to the number of arguments, though of course there are contract size and gas limits that apply. The following nonsensical example is valid solidity: contract ExampleContract {
  event Numbers(uint256, uint256, uint256, uint256, uint256, uint256, uint256, uint256);
} Similarly, there is no intrinsic limit to the length of strings or arrays stored in a log. However, there cannot be more than three indexed arguments (topics) in an event. An anonymous event can have 4 indexed arguments (we will cover this distinction later). An argument with zero events is also valid. Variable names in events are optional but recommended The following events behave identically event NewOwner(address newOwner);
event NewOwner(address); In general, including the variable name would be ideal because the semantics behind the following example are very ambiguous (this is not how you should declare events!) event Trade(address,address,address,uint256,uint256); We can guess that the addresses correspond to the sender, and the token addresses, while the uint256es correspond to the amounts, but this is hard to decipher. It is conventional to capitalize the name of an event, but the compiler does not require it. This would be a much better declaration: event Trade(address trader, address token1, address token2, uint256 token1Amount, uint256 token2Amount); Events can be inherited through parent contracts and interfaces When an event is declared in a parent contract, it can be emitted by the child contract. Events are internal and cannot be modified to be private or public. Here is an example: contract ParentContract {
  event NewNumber(uint256 number);

  function doSomething(uint256 number) public {
    emit NewNumber(number);
  }
}

contract ChildContract is ParentContract {
  function doSomethingElse(uint256 number) public {
    emit NewNumber(number); // valid
  }
} Similarly, events can be declared in an interface and used in the child, as in the following example. interface IExampleInterface {
	event Deposit(address indexed sender, uint256 amount);
}

contract ExampleContract is IExampleInterface {
	function deposit() external payable {
		emit Deposit(msg.sender, msg.value); // also valid
	}
} Event selector The EVM (Ethereum Virtual Machine) identifies events with the keccak256 of their signature. For solidity versions 0.8.15 or higher, you can also retrieve the selector using the .selector member. pragma solidity ^0.8.15;
contract ExampleContract {

    event SomeEvent(uint256 blocknum, uint256 indexed timestamp);

    function selector() external pure returns (bool) {

        // true
        return SomeEvent.selector == keccak256("SomeEvent(uint256,uint256)");
    }
} The event selector is actually a topic itself (we will discuss this further in a later section). Marking variables as indexed or not does not change the selector. Anonymous events Events can be marked as anonymous, in which case they will not have a selector. This means that client-side code cannot specifically isolate them as a subset like our earlier examples. The only way for client-side code to see an anonymous event is to get all events for the smart contract. pragma solidity ^0.8.15;
contract ExampleContract {

    event SomeEvent(uint256 blocknum, uint256 timestamp) anonymous;

    function selector() public pure returns (bool) {

        // ERROR: does not compile, anonymous events don't have selectors
        return SomeEvent.selector == keccak256("SomeEvent(uint256,uint256)");
    }
} Because the event signature is used as one of the indexes, an anonymous function can have four indexed topics, since the function signature is “freed up” as one of the topics. An anonymous event can have up to four indexed topics. A non-anonymous event can have up to three. contract ExampleContract {

    // valid
    event SomeEvent(uint256 indexed, uint256 indexed, address indexed, address indexed) anonymous;
} Anonymous events are rarely used in practice. Advanced topics about events This section describes events at the assembly level of the EVM. This section can be skipped for programmers new to . blockchain development Implementation detail: Bloom filters To retrieve every transaction that has happened with a smart contract, the Ethereum client would have to scan every block, which would be an extremely heavy I/O operation; but Ethereum uses an important optimization. Events are stored in a data structure for each block. A Bloom Filter is a probabilistic set that efficiently answers if a member is in the set or not. Instead of scanning the entire block, the client can ask the bloom filter if an event was emitted in the block. This allows the client to scan the blockchain much faster to find events. Bloom Filter Bloom Filters are probabilistic: they sometimes incorrectly return that an item is a member of the set even if it isn’t. The more members that are stored in a Bloom Filter, the higher the chance of error, and the larger the bloom filter must be (storage wise) to compensate for this. Because of this, Ethereum doesn’t store all the transactions in a Bloom Filter. There are far fewer events than there are transactions. This keeps the storage size on the blockchain manageable. When the client gets a positive membership response from a bloom filter, it must scan the block to verify the event took place. However, this will only happens for a tiny subset of blocks, so on average the Ethereum client saves a lot of computation by checking the bloom filter for event presence first. Yul Events In the Yul intermediate representation, the distinction between indexed arguments (topics) and unindexed arguments becomes clear. The following yul functions are available for emitting events (and their EVM opcode bears the same name). The table is copied from the with some simplification. yul documentation op code Usage log0(p, s) log without topics and data mem[p…(p+s)) log1(p, s, t1) log with topic t1 and data mem[p…(p+s)) log2(p, s, t1, t2) log with topics t1, t2 and data mem[p…(p+s)) log3(p, s, t1, t2, t3) log with topics t1, t2, t3 and data mem[p…(p+s)) log4(p, s, t1, t2, t3, t4) log with topics t1, t2, t3, t4 and data mem[p…(p+s)) A log can have up to 4 topics, but a non-anonymous solidity event can have up to 3 indexed arguments. That is because the first topic is used to store the event signature. There is no opcode or Yul function for emitting more than four topics. The unindexed parameters are simply abi encoded in the memory region [p…(p+s)) and emitted as one long byte sequence. Recall earlier that there was no limit in principle for how many unindexed arguments an event in Solidity can have. The underlying reason is that there is no explicit limit on how long the memory region pointed to in the first two parameters of the log op code takes. There is of course, limits provided by the contract size and memory expansion gas costs. Gas cost to emit solidity event Events are substantially cheaper than writing to storage variables. Events are not intended to be accessible by smart contracts, so the relative lack of overhead justifies a lower gas cost. The formula for how much gas an event costs is as follows ( ): source 375 + 375 * num_topics + 8 * data_size + mem_expansion cost Each event costs at least 375 gas. An additional 375 is paid for each indexed parameter. A non-anonymous event has the event selector as an indexed parameter, so that cost is included most of the time. Then we pay 8 times the number of 32 byte words written to the chain. Because this region is stored in memory before being emitted, the memory expansion cost must be accounted for also. In general, the intuition that the more you log the more you pay in gas, is accurate. Conclusion Events are for clients to quickly retrieve transactions that may be of interest. Although they don’t alter smart contract functionality, they allow the programmer to specify which transactions should be quickly retrievable. This makes it easier for dapps to quickly summarize important information. Events are relatively cheap gas-wise compared to storage, but the most important factor in their cost is the number of indexed parameters, assuming the coder does not use an inordinate amount of memory. Learn More Like what you see here? See our advanced to learn more. Solidity Bootcamp The lead image for this article was generated by HackerNoon's AI Image Generator via the prompt "Events in Solidity"

Solidity Events: A Comprehensive Overview

Eventos de solidez: una descripción completa

Événements Solidity : un aperçu complet

सॉलिडिटी इवेंट्स: एक व्यापक अवलोकन

Solidity イベント: 包括的な概要

Solidity Events: Uma Visão Abrangente

Sự kiện Solidity: Tổng quan toàn diện

Solidity 事件：全面概述

Authors:
(1) Ángel Merino, Department of Telematic Engineering Universidad Carlos III de Madrid {angel.merino@uc3m.es};
(2) José González-Cabañas, UC3M-Santander Big Data Institute {jose.gonzalez.cabanas@uc3m.es}
(3) Ángel Cuevas, Department of Telematic Engineering Universidad Carlos III de Madrid & UC3M-Santander Big Data Institute {acrumin@it.uc3m.es};
(4) Rubén Cuevas, Department of Telematic Engineering Universidad Carlos III de Madrid & UC3M-Santander Big Data Institute {rcuevas@it.uc3m.es}. Table of Links Abstract and Introduction LinkedIn Advertising Platform Background Dataset Methodology User’s Uniqueness on LinkedIn Nanotargeting proof of concept Discussion Related work Ethics and legal considerations Conclusions, Acknowledgments, and References Appendix 5 User’s Uniqueness on LinkedIn The results in the table show that using the location significantly reduces the number of skills required to identify users on LinkedIn uniquely. This reduction is roughly 2× for the random skill selection (i.e., Sk_R Vs. Lo_R) and 3×-4× for the least popular selection (i.e., Sk_LP Vs. Lo_LP). In the Lo_R scenario, 8, 14, and 23 skills are enough to make a user unique on LinkedIn with a probability of 50%, 75%, and 90%, respectively. For Lo_LP, the number of skills that make a user unique with those same probabilities is 3, 6, and 18, respectively. For the two scenarios that do not consider the user location, at least 28 skills are required to make a user unique with a probability ≥ 75%. If we look again at Figure 1, we observe that only around 30% of the users report 25 or more skills in their profile. This means that exclusively using the skills roughly reduces the nano-targetable users on LinkedIn to 1/3 of its user base. It is worth noting that this still represents a privacy risk for ∼250M LinkedIn users. Our data sample shows that 99% of the users on LinkedIn publicly share their location. In practice, the advertiser (attacker) willing to target an individual will be able to use the location in the vast majority of the cases, which reduces a lot the number of skills required to successfully nanotarget the user. In summary, our results show that the combination of the location and 6 rare skills reported by a user in their profile is enough to uniquely identify 3 out of 4 LinkedIn users. Increasing the number of skills to roughly 20 (rare or random) would allow uniquely identifying 9 out of 10 users. 5.1 Success Probability of Nanotargeting Campaigns Figure 5 shows the expected success probability (y-axis) of a nanotargeting campaign based on the combination of the location and N skills (x-axis). The figure depicts an upper bound for the success probability (red line) computed for the case where the least popular skills are selected and a lower bound (blue line) that refers to the random selection approach. The results suggest that an advertiser would need to use (roughly) between 5-8 skills more to achieve the same success probability when applying the random skills selection instead of the least popular skills selection. This is true except for very high success probabilities, such as 95%, where both strategies require a very similar number of skills. From a practical point of view, an advertiser willing to nanotarget an individual would use all the skills the individual reports in her profile because the cost of retrieving 1 or 40 skills is the same. If an advertiser selects all the skills, the random and least popular skill selection becomes the same strategy. Therefore, the success probability of a nanotargeting campaign is actually bounded by the amount of skills users report in their profiles. The more skills users report the more vulnerable they are to nanotargeting attacks. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Ángel Merino, Department of Telematic Engineering Universidad Carlos III de Madrid {angel.merino@uc3m.es}; (2) José González-Cabañas, UC3M-Santander Big Data Institute {jose.gonzalez.cabanas@uc3m.es} (3) Ángel Cuevas, Department of Telematic Engineering Universidad Carlos III de Madrid & UC3M-Santander Big Data Institute {acrumin@it.uc3m.es}; (4) Rubén Cuevas, Department of Telematic Engineering Universidad Carlos III de Madrid & UC3M-Santander Big Data Institute {rcuevas@it.uc3m.es}. Authors: Authors: (1) Ángel Merino, Department of Telematic Engineering Universidad Carlos III de Madrid {angel.merino@uc3m.es}; (2) José González-Cabañas, UC3M-Santander Big Data Institute {jose.gonzalez.cabanas@uc3m.es} (3) Ángel Cuevas, Department of Telematic Engineering Universidad Carlos III de Madrid & UC3M-Santander Big Data Institute {acrumin@it.uc3m.es}; (4) Rubén Cuevas, Department of Telematic Engineering Universidad Carlos III de Madrid & UC3M-Santander Big Data Institute {rcuevas@it.uc3m.es}. Table of Links Abstract and Introduction Abstract and Introduction LinkedIn Advertising Platform Background LinkedIn Advertising Platform Background Dataset Dataset Methodology Methodology User’s Uniqueness on LinkedIn User’s Uniqueness on LinkedIn Nanotargeting proof of concept Nanotargeting proof of concept Discussion Discussion Related work Related work Ethics and legal considerations Ethics and legal considerations Conclusions, Acknowledgments, and References Conclusions, Acknowledgments, and References Appendix Appendix 5 User’s Uniqueness on LinkedIn The results in the table show that using the location significantly reduces the number of skills required to identify users on LinkedIn uniquely. This reduction is roughly 2× for the random skill selection (i.e., Sk_R Vs. Lo_R) and 3×-4× for the least popular selection (i.e., Sk_LP Vs. Lo_LP). In the Lo_R scenario, 8, 14, and 23 skills are enough to make a user unique on LinkedIn with a probability of 50%, 75%, and 90%, respectively. For Lo_LP, the number of skills that make a user unique with those same probabilities is 3, 6, and 18, respectively. For the two scenarios that do not consider the user location, at least 28 skills are required to make a user unique with a probability ≥ 75%. If we look again at Figure 1, we observe that only around 30% of the users report 25 or more skills in their profile. This means that exclusively using the skills roughly reduces the nano-targetable users on LinkedIn to 1/3 of its user base. It is worth noting that this still represents a privacy risk for ∼250M LinkedIn users. Our data sample shows that 99% of the users on LinkedIn publicly share their location. In practice, the advertiser (attacker) willing to target an individual will be able to use the location in the vast majority of the cases, which reduces a lot the number of skills required to successfully nanotarget the user. In summary, our results show that the combination of the location and 6 rare skills reported by a user in their profile is enough to uniquely identify 3 out of 4 LinkedIn users. Increasing the number of skills to roughly 20 (rare or random) would allow uniquely identifying 9 out of 10 users. 5.1 Success Probability of Nanotargeting Campaigns Figure 5 shows the expected success probability (y-axis) of a nanotargeting campaign based on the combination of the location and N skills (x-axis). The figure depicts an upper bound for the success probability (red line) computed for the case where the least popular skills are selected and a lower bound (blue line) that refers to the random selection approach. The results suggest that an advertiser would need to use (roughly) between 5-8 skills more to achieve the same success probability when applying the random skills selection instead of the least popular skills selection. This is true except for very high success probabilities, such as 95%, where both strategies require a very similar number of skills. From a practical point of view, an advertiser willing to nanotarget an individual would use all the skills the individual reports in her profile because the cost of retrieving 1 or 40 skills is the same. If an advertiser selects all the skills, the random and least popular skill selection becomes the same strategy. Therefore, the success probability of a nanotargeting campaign is actually bounded by the amount of skills users report in their profiles. The more skills users report the more vulnerable they are to nanotargeting attacks. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

How Location and Skills Affect LinkedIn User Uniqueness on LinkedIn

How are you, hacker?
🪐 has got you covered with fresh content from our trending stories of the day! Set email preference . Want to know what's trending right now?: The Techbeat by HackerNoon here How to Use an Uncensored AI Model and Train It With Your Data By [ 3 Min read ]
Learn how to run Mixtral locally and have your own AI-powered terminal, remove its censorship, and train it with the data you want. @jeferson Read More. This Guy Thinks Wearing Pink Will Get You to Like Him By [ 5 Min read ]
Edward Sturm wants to be the nerd Gary Vee and is getting there by going all in on content optimizations and automations. @hcss11 Read More. ZKFair‘s Gas Fee Airdrop Community Guide: The Countdown Begins! By [ 2 Min read ]
The ZKFair gas fee airdrop will launch on December 23 at 11:00 AM (UTC+8), with a cap of $3 million USDC, available on a first-come, first-served basis @lumoz Read More. Navigating the 2024 NFT Landscape: A Humorous Look at 10 Key Predictions By [ 8 Min read ]
2024's NFT Frontier: 10 Humorous Predictions Unveiled. New Trump-themed NFTs, a DAO for the White House, time travel and Elizabeth Warren gets
into crypto. @audreynesbitt Read More. The Dating Game: Finding Your Perfect DevOps Match By [ 16 Min read ]
Finding the match in the world of DevOps can be quite challenging. It's like navigating the dating scene, where you need to seek out someone who shares your ... @samsey Read More. Demystifying ZKFair's Tokenomic Model By [ 3 Min read ]
Explore the groundbreaking testnet launch of ZKFair, the community-driven xZK L2 network, aiming to address challenges in the ZK L2 ecosystem. @lumoz Read More. Migrating from WebGL to WebGPU By [ 13 Min read ]
Moving to the upcoming WebGPU means more than just switching graphics APIs. It's also a step towards the future of web graphics. @dmitrii Read More. How to Create SVG Sprite With Icons By [ 10 Min read ]
The best way to use SVG icons is to create an SVG sprite. Here's an easy tutorial for beginners and pros alike. @gmakarov Read More. 67 Stories To Learn About Solana By [ 10 Min read ]
Learn everything you need to know about Solana via these 67 free HackerNoon stories. @learn Read More. Redesigning Apps Using Ruby On Rails: The Risks and The Risk-Free Approaches By [ 4 Min read ]
Learn how to apply the new design to a Ruby on Rails app without risks to your business and do that cheaper. @ka8725 Read More. The Zero Knowledge Proofs Writing Contest: Winner Announced! By [ 3 Min read ]
Hello Hackers! Welcome to the winner announcement of the Zero Knowledge Proof Writing Contest by Rareskills and HackerNoon. @hackernooncontests Read More. GAM3 Awards Crowns Best Web3 Games & Creator in 2023 By [ 3 Min read ]
The winners of the GAM3 Award 2023 have been crowned! Read on and learn more. @hackernoonevents Read More. Unveiling the Web 2.5 Documentary: Navigating the Future of the Internet By [ 6 Min read ]
Explore the internet's evolution in the HackerNoon Web 2.5 documentary. From inception to Web 3's questions, dive into Web 2.0's challenges. Move forward fast. @normbond Read More. You're Not Building a Personal Brand; You're Just Posting on LinkedIn By [ 4 Min read ]
Posting on LinkedIn like it’s some type of ritual isn’t building a personal brand. It can get you to destination A, for sure, but you won’t go far. @deepikapundora Read More. EstimateGPT: Software Development Planning Assistant By [ 2 Min read ]
EstimateGPT is a custom GPT tool designed to quickly draft project estimates and facilitate project planning. @olegguryanov Read More. Tech Innovations We're Excited About for By [ 3 Min read ]
Numerous tech disciplines will soon see greater leaps than before such as machine learning algorithms @shan-ge Read More. How Do You Create Value for a Product? By [ 6 Min read ]
Exploring why product value outweighs cost in consumer decisions, with insights from digital marketer Julia Goncharenko. @liasite Read More. Top 5 Picks for Gaming Web Browsers By [ 6 Min read ]
Elevate your gaming experience with the top 5 gaming web browsers. Explore our blog for the ultimate gaming browser selection. @oliviaames Read More. Resolving the 10 Common Javascript Errors By [ 22 Min read ]
While JS is versatile and powerful, it can often be a source of frustration due to various errors. @freefullstack Read More. Reviewing Celo, The Carbon-Negative, Mobile-first Blockchain By [ 8 Min read ]
Celo (CELO), the carbon-negative, mobile-first blockchain dedicated to “creating conditions of prosperity for all” through regenerative finance will get a SWOT. 🧑‍💻 What happened in your world this week? It's been said that , , . Feeling stuck? We got you covered ⬇️⬇️⬇️ We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.
See you on Planet Internet! With love,
The HackerNoon Team ✌️ @andreydidovskiy Read More. writing can help consolidate technical knowledge establish credibility and contribute to emerging community standards ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME

The TechBeat: How to Use an Uncensored AI Model and Train It With Your Data (12/29/2023)

How are you, hacker?
🪐 has got you covered with fresh content from our trending stories of the day! Set email preference . Want to know what's trending right now?: The Techbeat by HackerNoon here How to Use an Uncensored AI Model and Train It With Your Data By [ 3 Min read ]
Learn how to run Mixtral locally and have your own AI-powered terminal, remove its censorship, and train it with the data you want. @jeferson Read More. Demystifying ZKFair's Tokenomic Model By [ 3 Min read ]
Explore the groundbreaking testnet launch of ZKFair, the community-driven xZK L2 network, aiming to address challenges in the ZK L2 ecosystem. @lumoz Read More. Real-life LLM Implementation: A Backender’s Perspective By [ 7 Min read ]
In this article, I would like to explore the advantages and disadvantages of various large language models and share thoughts on potential issues @shcherbanich Read More. This Guy Thinks Wearing Pink Will Get You to Like Him By [ 5 Min read ]
Edward Sturm wants to be the nerd Gary Vee and is getting there by going all in on content optimizations and automations. @hcss11 Read More. ZKFair‘s Gas Fee Airdrop Community Guide: The Countdown Begins! By [ 2 Min read ]
The ZKFair gas fee airdrop will launch on December 23 at 11:00 AM (UTC+8), with a cap of $3 million USDC, available on a first-come, first-served basis @lumoz Read More. Migrating from WebGL to WebGPU By [ 13 Min read ]
Moving to the upcoming WebGPU means more than just switching graphics APIs. It's also a step towards the future of web graphics. @dmitrii Read More. Scaling the Development Team Alongside Business Growth: From the Ground Up to Market Entry By [ 8 Min read ] @ekorneeff Explore the intricacies of product-led tech companies' development dilemmas, from forming the right team and choosing development paths to scaling efficiently. Read More. Navigating the 2024 NFT Landscape: A Humorous Look at 10 Key Predictions By [ 8 Min read ]
2024's NFT Frontier: 10 Humorous Predictions Unveiled. New Trump-themed NFTs, a DAO for the White House, time travel and Elizabeth Warren gets
into crypto. @audreynesbitt Read More. How to Speed Up A Cypress Test Suite Execution: Techniques to Improve Your Experience By [ 4 Min read ]
Explore standard and advanced Cypress techniques your DevOps team can use to speed up test execution without sacrificing software quality. @launchable Read More. The Dating Game: Finding Your Perfect DevOps Match By [ 16 Min read ]
Finding the match in the world of DevOps can be quite challenging. It's like navigating the dating scene, where you need to seek out someone who shares your ... @samsey Read More. How to Create SVG Sprite With Icons By [ 10 Min read ]
The best way to use SVG icons is to create an SVG sprite. Here's an easy tutorial for beginners and pros alike. @gmakarov Read More. Balancing Risk and Opportunity: Institutions Can’t Afford to Ignore Crypto Any Longer By [ 6 Min read ]
Can the ever-evolving world of crypto remain outside of mainstream adoption for much longer? @dmytrospilka Read More. Craig Wright Is NOT Satoshi Nakamoto By [ 32 Min read ]
Craig Wright Is Not Satoshi Nakamoto @spfreaks Read More. Easy Blooket Hacks to Help You Play More Games and Get More Tokens By [ 6 Min read ]
Learn how to hack Blooket so you can play more games! @kingabimbola Read More. Redesigning Apps Using Ruby On Rails: The Risks and The Risk-Free Approaches By [ 4 Min read ]
Learn how to apply the new design to a Ruby on Rails app without risks to your business and do that cheaper. @ka8725 Read More. EstimateGPT: Software Development Planning Assistant By [ 2 Min read ]
EstimateGPT is a custom GPT tool designed to quickly draft project estimates and facilitate project planning. @olegguryanov Read More. Gaming Across Generations—A Comparative Study By [ 7 Min read ]
Video games are weaving their pixel magic into everyone's lives, from your tech-savvy nephew to your grandma who still thinks 'Nintendo' is a new type of pasta. @beatboyninja Read More. 67 Stories To Learn About Solana By [ 10 Min read ]
Learn everything you need to know about Solana via these 67 free HackerNoon stories. @learn Read More. The Zero Knowledge Proofs Writing Contest: Winner Announced! By [ 3 Min read ]
Hello Hackers! Welcome to the winner announcement of the Zero Knowledge Proof Writing Contest by Rareskills and HackerNoon. @hackernooncontests Read More. Can Humane's AI Pin Survive the Test of Time? By [ 10 Min read ]
Humane came into the scene with such an awesome prospect. With a solid financial backing of over 200 million USD, will it survive the future? 🧑‍💻 What happened in your world this week? It's been said that , , . Feeling stuck? We got you covered ⬇️⬇️⬇️ We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.
See you on Planet Internet! With love,
The HackerNoon Team ✌️ @sammynathaniels Read More. writing can help consolidate technical knowledge establish credibility and contribute to emerging community standards ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME

Stories, News & Mentions about RARESKILLS

Rareskills’s Stories on HackerNoon

Rareskills's News & Mentions