ETH_HASH(1) eth-hash ETH_HASH(1)

eth_hash - مستندات eth-hash

تابع درهم‌سازی اتریوم، keccak256، که گاهی (به اشتباه) sha3 نامیده می‌شود

python -m pip install eth-hash

اگر مطمئن نیستید، "pycryptodome" را انتخاب کنید زیرا از pypy3 پشتیبانی می‌کند.

می‌توانید فهرست کاملی از هر یک از بک‌اندهای پشتیبانی‌شده کنونی را در eth_hash.backends بیابید.

بک‌اندی را که می‌خواهید استفاده کنید هنگام نصب درون کروشه قرار دهید، مانند:

python -m pip install "eth-hash[pycryptodome]"

>>> from eth_hash.auto import keccak
>>> keccak(b'')
b"\xc5\xd2F\x01\x86\xf7#<\x92~}\xb2\xdc\xc7\x03\xc0\xe5\x00\xb6S\xca\x82';{\xfa\xd8\x04]\x85\xa4p"

همچنین می‌توانید درهم‌سازها را به‌صورت فزاینده محاسبه کنید

>>> from eth_hash.auto import keccak
>>> preimage = keccak.new(b'part-a')
>>> preimage.update(b'part-b')
>>> preimage.digest()
b'6\x91l\xdd50\xd6[\x7f\xf9B\xff\xc9SW\x98\xc3\xaal\xd9\xde\xdd6I\xb7\x91\x9e\xf4`pl\x08'

شیء preimage بازگردانده‌شده را نیز می‌توان کپی کرد.

>>> from eth_hash.auto import keccak
>>> preimage = keccak.new(b'part-a')
>>> preimage_copy = preimage.copy()
>>> preimage.update(b'part-b')
>>> preimage.digest()
b'6\x91l\xdd50\xd6[\x7f\xf9B\xff\xc9SW\x98\xc3\xaal\xd9\xde\xdd6I\xb7\x91\x9e\xf4`pl\x08'
>>> preimage_copy.update(b'part-c')
>>> preimage_copy.digest()
b'\xffcy45\xea\xdd\xdf\x8e(\x1c\xfcF\xf3\xd4\xa1S\x0f\xdf\xd8\x01!\xb2(\xe1\xc7\xc6\xa3\x08\xc3\n\x0b'

اگر چندین بک‌اند نصب کرده‌اید، شاید بخواهید صراحتاً مشخص کنید که کدام‌یک بارگذاری شود. می‌توانید این کار را در یک متغیر محیطی یا در زمان اجرا مشخص کنید.

$ ETH_HASH_BACKEND="pysha3" python
>>> from eth_hash.auto import keccak
# This runs with the pysha3 backend
>>> keccak(b'')
b"\xc5\xd2F\x01\x86\xf7#<\x92~}\xb2\xdc\xc7\x03\xc0\xe5\x00\xb6S\xca\x82';{\xfa\xd8\x04]\x85\xa4p"

>>> from eth_hash.backends import pysha3
>>> from eth_hash import Keccak256
>>> keccak = Keccak256(pysha3)
>>> keccak(b'')
b"\xc5\xd2F\x01\x86\xf7#<\x92~}\xb2\xdc\xc7\x03\xc0\xe5\x00\xb6S\xca\x82';{\xfa\xd8\x04]\x85\xa4p"

بدون تغییرات قابل توجه.

•
حذف پشتیبانی از Python 3.8 و 3.9 (#66 https://github.com/ethereum/eth-hash/issues/66)

•
افزودن پشتیبانی از Python 3.14 (#66 https://github.com/ethereum/eth-hash/issues/66)

•
ادغام به‌روزرسانی‌های قالب، به‌ویژه افزودن پشتیبانی از py312 و آزمودن ساخت مستندات برای تمام قالب‌ها (#57 https://github.com/ethereum/eth-hash/issues/57)

•
حذف پشتیبانی از python 3.7 (#53 https://github.com/ethereum/eth-hash/issues/53)

•
افزودن پشتیبانی از Python 3.11 (#45 https://github.com/ethereum/eth-hash/issues/45)

•
ترجیح بک‌اند pysha3 به‌طور پیش‌فرض (#42 https://github.com/ethereum/eth-hash/issues/42)

•
افزودن پشتیبانی از Python 3.8، 3.9 و 3.10 (#40 https://github.com/ethereum/eth-hash/issues/40)

•
قطع پشتیبانی از Python 3.5 و 3.6 (#39 https://github.com/ethereum/eth-hash/issues/39)

•
#40 https://github.com/ethereum/eth-hash/issues/40، #41 https://github.com/ethereum/eth-hash/issues/41

•
بک‌اند Keccak در هر بار فراخوانی مقداردهی اولیه می‌شد. اکنون فقط در نخستین فراخوانی مقداردهی می‌شود. (#36 https://github.com/ethereum/eth-hash/issues/36)

•
حذف فایل‌های venv از نسخه انتشار از طریق MANIFEST.in (#38 https://github.com/ethereum/eth-hash/issues/38)

•
حذف نیاز به وابستگی eth-utils جهت رفع چرخه وابستگی (#33 https://github.com/ethereum/eth-hash/issues/33)

•
رفع اشکال در برون‌ریزی حاشیه‌نویسی‌های نوع (type annotations) (#28 https://github.com/ethereum/eth-hash/issues/28)

•
برون‌ریزی حاشیه‌نویسی‌های نوع جهت استفاده در پروژه‌های واردکننده (#29 https://github.com/ethereum/eth-hash/issues/29)

•
اعمال به‌روزرسانی‌های ۳ ساله از قالب پروژه (#29 https://github.com/ethereum/eth-hash/issues/29)

منتشرشده در ۵ سپتامبر ۲۰۱۸

•
تنظیم نگارش pycryptodome روی >=3.6.6,<4 جهت رفع یک آسیب‌پذیری تازه‌کشف‌شده

منتشرشده در ۲۸ مه ۲۰۱۸

•
اطمینان از pickleable بودن بک‌اند auto (#19)

منتشر شده در ۱۴ مه ۲۰۱۸

•
بک‌اند pycryptodome اکنون امکان فراخوانی update()، سپس digest() و پس از آن دوباره update() را فراهم می‌کند.

منتشر شده در ۲ آوریل ۲۰۱۸

•
اکنون می‌توانید eth-hash را بدون یک بک‌اند وارد (import) کنید؛ برنامه تا زمانی که برای تولید هش تلاشی صورت نگیرد، با خطا متوقف نخواهد شد.

منتشر شده در ۱۵ مارس ۲۰۱۸

  • ارتقای pycryptodome به نسخهٔ v3.5.1+
  • بهبودهای کارایی در کار با preimage
  • مستندات و آزمون‌های بهتر

منتشر شده در ۲۸ فوریه ۲۰۱۸

منتشر شده در ۷ فوریه ۲۰۱۸

  • افزودن پشتیبانی از بک‌اند pycryptodome
  • افزودن پشتیبانی از بک‌اند pysha3
  • امکان تعیین بک‌اند از طریق متغیر محیطی ETH_HASH_BACKEND
  • مستندات جدید شروع سریع <#quickstart>

منتشر شده در ۶ فوریه ۲۰۱۸

•
رفع باگ ارجاع pypy3 در pypi

•
راه‌اندازی مخزن، ثبت نام‌ها برای pip، RTD، github و غیره

از علاقهٔ شما به مشارکت سپاسگزاریم! ما از همهٔ مشارکت‌ها بدون در نظر گرفتن میزان آن‌ها استقبال می‌کنیم. لطفاً این راهنما را برای آشنایی با نحوهٔ شروع مطالعه کنید. اگر با مشکلی مواجه شدید، می‌توانید در سرور دیسکورد Ethereum Python درخواست کمک کنید https://discord.gg/GHryRvPB84.

برای شروع، مخزن را به حساب github خود فورک کنید، سپس آن را در سامانهٔ توسعهٔ خود شبیه‌سازی (clone) نمایید:

git clone git@github.com:your-github-username/eth-hash.git

در مرحله بعد، وابستگی‌های توسعه را نصب کنید. توصیه می‌کنیم از یک محیط مجازی (virtual environment) مانند virtualenv استفاده کنید https://virtualenv.pypa.io/en/stable.

cd eth-hash
virtualenv -p python venv
. venv/bin/activate
python -m pip install -e ".[dev]"
pre-commit install

یک راه عالی برای کاوش در پایگاه کد، اجرای آزمون‌ها است.

می‌توانیم همهٔ آزمون‌ها را با دستور زیر اجرا کنیم:

pytest tests

ما از pre-commit https://pre-commit.com برای اعمال یک سبک کدنویسی یکپارچه در سرتاسر کتابخانه استفاده می‌کنیم. این ابزار با هر کامیت به‌صورت خودکار اجرا می‌شود، اما می‌توانید آن را به‌صورت دستی نیز با دستور زیر اجرا کنید:

make lint

اگر نیاز به ثبت کامیتی دارید که بررسی‌های pre-commit را نادیده بگیرد، می‌توانید این کار را با git commit --no-verify انجام دهید.

این کتابخانه از type hints استفاده می‌کند که توسط ابزار mypy (بخشی از بررسی‌های pre-commit) اعمال می‌شوند. تمامی کدهای جدید، به‌استثنای کدهای درون دایرکتوری tests، باید حتماً همراه با type hints ارائه شوند.

مستندات خوب منجر به پذیرش سریع‌تر و رضایت بیشتر کاربران خواهد شد. لطفاً راهنمای ما دربارهٔ نحوهٔ ایجاد مستندات برای زیست‌بوم Python Ethereum را در https://github.com/ethereum/snake-charmers-tactical-manual/blob/main/documentation.md بررسی کنید.

ایجاد زودهنگام pull requestها ایدهٔ بسیار خوبی است. یک pull request نشان‌دهندهٔ آغاز یک گفتگو است و لزوماً نیازی نیست که یک ارسال نهایی و کامل‌شده باشد.

مستندات GitHub برای کار روی درخواست‌های ادغام در اینجا https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests در دسترس است.

پس از ایجاد pull request، وضعیت ساخت (build) در Circle CI را در واسط کاربری GitHub بررسی کرده و مطمئن شوید که تمام آزمون‌ها با موفقیت پاس می‌شوند. به‌طور کلی، درخواست‌های ادغامی که هنوز ساخت CI آن‌ها پاس نشده است، بررسی (review) نخواهند شد مگر اینکه صراحتاً درخواست شده باشد.

اگر pull request تغییراتی ایجاد می‌کند که باید در یادداشت‌های انتشار (release notes) منعکس شوند، لطفاً یک فایل newsfragment اضافه کنید، همان‌گونه که در اینجا https://github.com/ethereum/eth-hash/blob/main/newsfragments/README.md توضیح داده شده است.

در صورت امکان، تغییر فایل یادداشت‌های انتشار باید در همان کامیتی قرار گیرد که ویژگی جدید یا رفع باگ را معرفی می‌کند.

انتشارها معمولاً از شاخهٔ main انجام می‌شوند، به‌جز زمان انتشار یک نسخهٔ بتا (که در این حالت نسخهٔ بتا از main منتشر شده و شاخهٔ پایدار قبلی از همان شاخهٔ مربوطه منتشر می‌شود).

پیش از انتشار یک نسخهٔ جدید، بسته‌ای را که قرار است منتشر شود ساخته و آزمایش کنید:

git checkout main && git pull
make package-test

این دستور بسته را می‌سازد و آن را در یک محیط مجازی (venv) موقت نصب می‌کند. دستورالعمل‌ها را برای فعال‌سازی venv دنبال کنید و هر آنچه را که فکر می‌کنید مهم است بیازمایید.

مستنداتی را که قرار است منتشر شوند بازبینی کنید:

make docs

یادداشت‌های انتشار را اعتبارسنجی کرده و پیش‌نمایش آن‌ها را بررسی کنید:

make validate-newsfragments

پیش از ارتقای شماره نسخه، یادداشت‌های انتشار (release notes) را بسازید. شما باید بخشی از نسخه را که ارتقا می‌یابد (در زیر ببینید) لحاظ کنید، که این امر نحوه نمایش شماره نسخه را در یادداشت‌های انتشار تغییر می‌دهد.

make notes bump=$$VERSION_PART_TO_BUMP$$

در صورت بروز هرگونه خطا، حتماً دستور make notes را تا زمان رفع مشکل مجدداً اجرا کنید.

پس از اطمینان از صحت بسته انتشار، نسخه جدید را منتشر کنید:

make release bump=$$VERSION_PART_TO_BUMP$$

این دستور اقدامات زیر را انجام می‌دهد:

  • شماره نسخه را طبق موارد مشخص‌شده در .pyproject.toml و setup.py ارتقا می‌دهد.
  • یک commit و tag در git برای نسخه جدید ایجاد می‌کند.
  • بسته را کامپایل و می‌سازد.
  • commit و tag را به github ارسال (push) می‌کند.
  • فایل‌های بسته جدید را به pypi ارسال (push) می‌کند.

مقدار $$VERSION_PART_TO_BUMP$$ باید یکی از این مقادیر باشد: major، minor، patch، stage، یا devnum.

قالب شماره‌گذاری نسخه در این مخزن برای نسخه‌های پایدار {major}.{minor}.{patch}، و برای نسخه‌های ناپایدار {major}.{minor}.{patch}-{stage}.{devnum} است (stage می‌تواند alpha یا beta باشد).

اگر در نسخه beta هستید، اجرای make release bump=stage نسخه را به حالت پایدار تغییر می‌دهد.

برای ارائه یک نسخه ناپایدار زمانی که نسخه فعلی پایدار است، نسخه جدید را به‌طور صریح مشخص کنید، مانند make release bump="--new-version 4.0.0-alpha.1"

می‌توانید نتیجه ارتقای هر بخش از نسخه را با دستور زیر مشاهده کنید: bump-my-version show-bump

در راستای ایجاد فضایی باز، پرنشاط و پذیرا، ما مشارکت‌کنندگان و نگه‌دارندگان متعهد می‌شویم که مشارکت در پروژه و جامعه‌مان برای همگان، صرف‌نظر از سن، اندازه اندام، معلولیت، قومیت، هویت و بیان جنسیتی، سطح تجربه، میزان تحصیلات، موقعیت اجتماعی-اقتصادی، ملیت، ظاهر فردی، نژاد، دین، یا هویت و گرایش جنسی، تجربه‌ای به‌دور از هرگونه آزار و اذیت باشد.

نمونه‌هایی از رفتارهایی که به ایجاد فضایی مثبت کمک می‌کنند عبارتند از:

  • استفاده از ادبیات پذیرا، محترمانه و فراگیر
  • احترام گذاشتن به دیدگاه‌ها و تجربیات گوناگون
  • پذیرش شایسته و متواضعانه انتقادهای سازنده
  • تمرکز بر آنچه بیشترین منفعت را برای جامعه به همراه دارد
  • ابراز همدلی و درک متقابل نسبت به سایر اعضای جامعه

نمونه‌هایی از رفتارهای غیرقابل قبول توسط مشارکت‌کنندگان عبارتند از:

  • استفاده از کلمات یا تصاویر جنسی و هرگونه توجه یا پیشروی جنسی ناخواسته
  • رفتارهای مخرب (trolling)، نظرات توهین‌آمیز/تحقیرآمیز و حملات شخصی یا سیاسی
  • ایجاد هرگونه آزار و اذیت علنی یا خصوصی
  • افشای اطلاعات خصوصی دیگران، مانند نشانی فیزیکی یا پست الکترونیکی، بدون اجازه صریح آنان
  • سایر رفتارهایی که منطقاً در یک محیط حرفه‌ای نامناسب و ناپسند تلقی می‌شوند

    نگه‌دارندگان پروژه مسئول شفاف‌سازی معیارهای رفتار قابل‌قبول هستند و انتظار می‌رود در واکنش به هرگونه رفتار غیرقابل‌قبول، اقدامات اصلاحی مناسب و عادلانه‌ای اتخاذ کنند.

    نگه‌دارندگان پروژه این حق و مسئولیت را دارند که دیدگاه‌ها، کامیت‌ها، کدها، ویرایش‌های ویکی، issueها و سایر مشارکت‌هایی را که با این مرام‌نامه رفتاری همسو نیستند حذف، ویرایش یا رد کنند، یا هر مشارکت‌کننده‌ای را به دلیل سایر رفتارهایی که نامناسب، تهدیدآمیز، توهین‌آمیز یا مضر تشخیص می‌دهند، به‌طور موقت یا دائم مسدود نمایند.

این مرام‌نامه رفتاری هم در فضاهای پروژه و هم در فضاهای عمومی هنگامی که فردی نماینده پروژه یا جامعه آن است، اعمال می‌شود. نمونه‌های نمایندگی یک پروژه یا جامعه شامل استفاده از نشانی رایانامه رسمی پروژه، ارسال پست از طریق حساب رسمی رسانه‌های اجتماعی، یا فعالیت به عنوان نماینده تعیین‌شده در یک رویداد آنلاین یا حضوری (آفلاین) است. بازنمایی و نمایندگی پروژه ممکن است توسط نگه‌دارندگان پروژه بیشتر تعریف و شفاف‌سازی شود.

موارد مربوط به رفتارهای سوءاستفاده‌گرایانه، آزاردهنده یا به هر نحو غیرقابل‌قبول را می‌توان از طریق تماس با تیم پروژه به نشانی <snakecharmers@ethereum.org> گزارش کرد. تمامی شکایت‌ها بازبینی و بررسی خواهند شد و پاسخی که با توجه به شرایط لازم و مناسب تشخیص داده شود ارائه خواهد گردید. تیم پروژه متعهد به حفظ محرمانگی هویت گزارش‌دهنده حادثه است. جزئیات بیشتر در مورد خط‌مشی‌های اجرایی خاص ممکن است به‌طور جداگانه منتشر شود.

نگه‌دارندگان پروژه‌ای که این مرام‌نامه رفتاری را با حسن نیت رعایت نکنند یا به اجرا درنیاورند، ممکن است بنا به تصمیم سایر اعضای رهبری پروژه با پیامدهای موقت یا دائمی مواجه شوند.

این مرام‌نامه رفتاری از Contributor Covenant اقتباس شده است https://www.contributor-covenant.org، نسخه 1.4، در دسترس در https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

  • نمایه <>
  • نمایه ماژول <>

بنیاد اتریوم (The Ethereum Foundation)

2018-2025, The Ethereum Foundation

March 29, 2026 0.8